Re: MAC address issue

[Sean Boudreau <seanb%qnx.com@localhost>]

On Fri, Jan 18, 2008 at 12:01:20PM -0500, David Young wrote:
> 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.
> 

Sounds good to me.

-seanb