Re: MAC address issue

[David Young <dyoung%pobox.com@localhost>]

On Fri, Jan 18, 2008 at 10:40:06AM +0000, Sean Boudreau wrote:
> On Thu, Jan 17, 2008 at 03:50:27PM -0500, Joerg Sonnenberger wrote:
> > On Thu, Jan 17, 2008 at 02:39:07PM -0600, David Young wrote:
> > > I will work on it this weekend.  I think that add/delete semantics are
> > > desirable for link-layer addresses (lladdrs), however, we need to apply
> > > several restrictions in the short term:
> > 
> > I don't think all this complexity buys any real advantage. If the only
> > real improvement is the ability to restore the factory default, a copy
> > of it would be more than enough. None of your examples shows what it is
> > useful for.
> > 
> > Joerg
> 
> I don't see what 'preference' is useful for.  It seems

My thought about the preference was as follows: the preference provides
for a predictable "succession" if the active lladdr is deleted.  ifaddrs
already have preference numbers, so we can re-use an existing mechanism.

Now that you mention it, I see some problems with using the preference
number in this way.  The first problem is that userland cannot add an
address simultaneously with setting its preference (perhaps we should
allow that, though), so the kernel would have to auto-assign a unique
preference.  I don't like the idea of that at all.

> reasonable to have a 'factory' flag which can't be deleted,
> others can be added / removed, only one can be active?

Let us put aside lladdr preferences, and use only the 'active' flag,
instead.  Only one lladdr may be active at a time, deleting an active
lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
clears the 'active' state on every other lladdr.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24