[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MAC address issue
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.
Main Index |
Thread Index |