[ `wildboar' description]

That certainly sounds better than what we have now.  Long-term, I
htink we need more dynamic config, but htis is a very useful step in
the right direction.  but the final say is by consensus or Core, not I.

But - in no particular order:

  *  Does this mean one kernel thread per slot per supported device,
     or just one kernel thread per slot, which dispatches events
     to the correct attachment?
     that sounds like a lot of kernel threads. Do they all show
     up in ps output?

  * We currently test if a device is present by looking at the autoconfig
    tree.  In `wildboar',  Are devices which arent physically present
    (attached at autoconfig time, but not yet dyn_attach()'ed)  visible
    as `real' devices?
    That sounds like a nasty flaw. all possible nics devices will
    will show up to ifconfig, even if they're not present.
    Very confusing.   What will that do to routing, if ipforwarding
    is turned on (say, for a mobile router?)  Yikes.

 * If that's what you are getting at with the problems of wildcarded
   devices -- i agree.

 * wont this  be even worse when we add support for cardbus
   devices, as well as pcmcia cards, in a given slot?

Can we maybe attack some of these by (conceptually) rerunning
autoconfig on card insert/delete events, to attach the right driver to
whatever device is newly inserted in a given slot?

That is, extract the CIS tuples from the newly-inserted card, and then
call into config_found_sm() to find the correct driver (if any).


OTOH, I agree 100% about the mapping from MAC address to unit number.
We have to keep the unit<-> mac address mapping consistent across
hotswaps (but not reboots), or IPv6 and routing will go crazy.

Where we keep that state, I have no idea.