I think I've raised this issue here couple of months before.

>It appears that the card also has its mac address in its CIS records,
>which is accessible at attach time.  Amazingly enough, there appears
>to be a fairly standard way to do this across all PCMCIA NIC's.
>(excuse me for my astonishment at pc-class hardware getting something
>like this correct.. :-) )
>
>Going even further off the deep end...
>
>Support for binding cards to device instances by mac address would
>therefore appear to be somewhat more straightforward than I had
>previously thought.  It may be a bit of a stretch, but you could even
>use the mac address as something like a locator.  
>
>Compiling mac addresses into a kernel would be .. wrong .. but once a
>device had been attached using a wildcard config entry, it doesn't
>seem all that unreasonable to allow (but not require) the system to
>operate in a mode where the binding from mac address to device
>instance was remembered.

	The above is what BSDI pcmcia code does (called "wildboar", developed
	by WIDE/KAME folks).
	- On bootup time (without card in the slot) pcmcia network drivers
	  are attached without ethernet mac address.  If you attempt to send
	  outgoing packets it will fail, but the interface itself is already
	  there.  if you have 3 drivers, it will be like:
		eth0 - mac addr 0:0:0:0:0:0, no card
		eth1 - mac addr 0:0:0:0:0:0, no card
		eth2 - mac addr 0:0:0:0:0:0, no card
	  note: it should be straightforward to have wildcard config entry
	  (eth*) on kernel config file and add interface instance as necessary.
	- If card A is inserted, it will be related to a network driver
	  which has no MAC address recorded.  eth0 will record MAC address
	  for card A. you can throw packets to eth0.
		eth0 - mac addr for card A, card inserted
		eth1 - mac addr 0:0:0:0:0:0, no card
		eth2 - mac addr 0:0:0:0:0:0, no card
	- if you insert card B, similar event happen.  eth1 will be associated
	  with card B.
		eth0 - mac addr for card A, card inserted
		eth1 - mac addr for card B, card inserted
		eth2 - mac addr 0:0:0:0:0:0, no card
	- if you remove card A, eth0 will not be usable (raises run time
	  error).  the interface flag for eth0 is kept IFF_UP.
	  note: card power control is separate from IFF_UP.
		eth0 - mac addr for card A, no card
		eth1 - mac addr for card B, card inserted
		eth2 - mac addr 0:0:0:0:0:0, no card
	- if you insert card A again, it will be attached as eth0 not eth2.
		eth0 - mac addr for card A, card inserted
		eth1 - mac addr for card B, card inserted
		eth2 - mac addr 0:0:0:0:0:0, no card

	The reasons why we did this are as follows:
	- There's no good event notification model toward userland processes.
	  Suppose we want to run routing daemon on a notebook (yes we do this).
	  It is more friendly with existing codebase to hide insertion/removal
	  in the kernel, than show card removal to the userland as removal
	  of network interface.  Similar situation happens if you would
	  like to run getty on pcmcia modem card.  Network device is
	  much better as we may be able to add something into routing socket,
	  we have almost no hope for character devices like modem card.
	- Routing table setups, interface addresses and multicast group setups
	  will persist in the kernel so we needed to keep drivers, not
	  removing drivers (just as discussed by others).
	- In BSDI/wildboar, pcmcia slot and driver instance is separated.
	  you can move card A from slot 1 to slot 3, without changing
	  name of driver.  It happens many times due to physical constraint
	  in dongles (like card A and card B does not fit well in slot 1 and
	  slot 2, so I wanna move card A to slot 3).

	I'm not objecting the current rough consensus (?) in netbsd.  pcmcia
	devices are wacky thing to traditional unix model, as it has no
	good mechanism for hardware medium change notification toward userland.
	Basically it assumes that hardware devices are fixed at bootstrap time.
	Therefore, I believe there can be multiple ways to design how to deal
	with it.  I'm still not sure which is the right way (and I'm not sure
	if there's only single "right" way exists).
	BSDI/wildboar model worked very well for me.  If you care about
	this issue, I suggest you to try using it at least once.
	BSDI offers 60day evaluation license as shown in
	http://www.bsdi.com/products/evalcd/.

itojun