[cc: to port-i386 dropped for lack of relevance]

>    Today I would end up with smc99 and wd180, after some
>    iterations, which is completly bogus. With devices realy gone 
>    I would have to redo all the network configuration every time.

	Arranging to use the first-avaliable device number rather than
incrementing isn't a huge project, but doesn't seem like it's worth a
whole lot. Sort of implicit in what you're saying you want to do is
that you want a partition on the flash disk mounted, or the ethernet
interface brought up/down when the device goes in or out. Whatever
mechanisim is doing that at device insertion/removal time, human or
automated, can deal with being passed the device number. (Okay, so
/dev/wd* nodes get annoying. Still fixable.)

>The problem is that there may be device information kept at places where
>you don't expect it (May be implicitly in some daemon process). You can't  
>delete it all when the kernel wants to unconfigure the drive. (It would
>be a major effor I fear doing it on the kernel level only).
>I tried that a long time ago (for my old pcmcia code).

	The kernel is ours; we can fix it. User-level processes that
have files or devices open on the device that goes away will lose, and
will not cease losing just because a device with the same name comes
back. A daemon that kept a filename like "/flash/kodak/picture.01" to
poll would only "lose" in the sense of doing the wrong thing if
something inappropriate was mounted in /flash, which would likely
constitute pilot error.

>Well if I've two identical modems, the CIS may contain a manufacturer 
>serial number. 

	"May" in theory, I suppose, but I've yet to see a PCMCIA modem
with such a thing, and I've been staring at CIS tuples for random
modems a lot these last few weeks. 

>It would work on ethernetcards, most scsi-devices and can be made to work
>with removable devices (Floppy, Zip etc).
>The advantage is you prevent a loss if you have to do a rescan.

>If a device doesn't have a unique ID you can either use the current time,
>which results in a new devices everytime, or a constant number for a 
>certain position (pcmcia slot-id).

	Wired-config. Sure, we've got that. But after disconnecting the
device and having broken connections to user processes, reconnecting
the device and reattaching it in config-land doesn't give us a way to
reattach it to user processes, and it's not clear that we'd want to. 

	My sense is that is that there are very *few* cases where
trying to pretend that the device "went away" temporairly buys
anything. If I unplug and replug my modem card, it's dropped lots of
state, probably hanging up the phone line in the process. Not much
value in not treating it as a new device. Even in those few cases
where there is some kind of unique identifier associated with a device
that lets you say "yes, this is absolutely the same widget", the state
of the widget is very likely to be different enough to not be useful.

	I think the functionality you want can be much better
accomplished with a user-land daemon that can do things like notice
that an ethernet card was dropped in, and try to bring it up, or
notice the 10M flash card and mount it on /flash.

	- Nathan