>  *  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?

	I believe per-slot kernel thread is enough.

>  * 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.

	NetBSD relates IFF_UP/~IFF_UP with power state of the card.
	In wildboar they are totally separate.  we can make interface up
	while the card is not present, or while the slot is powered down.
	Slow power up/down is controlled by other ioctls.

	Usually interfaces without hardware is ~IFF_UP, so there should be
	no problem.  If it happens to be IFF_UP, xx_start() will check if
	the card is present or not, and if not present return some error
	(sorry forgot the exact error code).

	One way to change this behavior is to defer if_attach() until actual
	hardware insertion.

>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).

	foreach (pcmcia drivers) {
		if (xx_probe success)	/* check for cis tuple */
			break;
	}
	in slot watcher kernel thread should be enough.

>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.

	In BSDI version, this is done like below.
	Not very clean but works well.  This should better be implemented in
	pccard configuration logic, not in the driver.

itojun


xx_dyna_probe()
{
	int myunit;

	/* check for cis tuple matches */

	/* if the device is already handled by other unit, do not attach */
	for (unit = 0; unit < xxmax; unit++) {
		if (unit == myunit)
			continue;
		if (xxcd.cd_devs[unit]->sc_macaddr == card macaddr) {
			/* the card is handled by other unit */
			return 0;
		}
	}

	/* if I'm fresh driver attach this */
	if (xxcd.cd_devs[unit]->sc_macaddr == 0:0:0:0:0:0) {
		/* I'm fresh driver */
		xxcd.cd_devs[unit]->sc_macaddr = card macaddr;
		return 1;
	}

	/* if I've seen this card and I'm the driver for this, attach again */
	if (xxcd.cd_devs[unit]->sc_macaddr == card macaddr) {
		/* same card inserted again */
		return 1;
	}

	return 0;
}