Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
> well, since we're talking about NetBSD, the other place is in the
> locators in the "struct cfdata".  if we can dynamically add these on
> the fly (which you want to do if you want to support dynamic
> loading/unloading of drivers), rather than having them allocated in a
> single array as they are now, it becomes a simple matter of cloning
> the wildcard's cfdata into a more-specific cfdata with the appropriate
> locators in it..

I still think this is unnecessary, and probably "silly" to support.
It probably wouldn't be too hard to make config do the right thing
with non-integer-valued locators.  (though the notion of locators as
they exist now -- as attributes that locate the device on the parent
bus -- isn't quite correct.  the right thing is device- or
device-class-specific attributes which can be matched independent of
parent.)

In my opinion, in 90+% of the cases that Real Users care about, The
Right Thing to make network drivers do the right thing is to
automatically tell dhclient about the new interface when the new
interface is inserted (and tell it that one was removed when it was
removed 8-).

Most of the other 10% could be solved by wiring the device down,
though it might be a bit harder for people with this, in my opinion
odd, requirement.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.