In message <199808160917.FAA02488@road-runner.mit.edu>  "Nathan J. Williams" wrote:
> 
> >    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.)

For some devices (esp. network cards) really deleting a card for
a temporal removal is arkward. You loose way to much state in 
application programs (being bound to an address of the interface etc.)
I do have uptimes of 6 days and more on may laptop (unless I'm kernel-hacking)
and that includes travel to different networks (and even continents).

I think you could work around most of the pcmcia issues with a lot of userlevel
scripts/code, but device indentification has addtional benefits:

    *) Identifying devices (tapes / diskdrives) during rescans on a BUS
    *) Identity networkcards not based on their probe-order (worst example
	    3COM ISA cards ...)

I think the efford to provide this is not to big, just add a function 
to the devswitch for configuration issues which takes a opcode parameter and 
call it dev_config. One opcode would be DEV_IDENTIFY and the device can 
return a unique identifier or a cookie stating either its always the same
or never. Not having the function will say I'm nver the same and would
preserve current behaviour. 
Adding a DEV_DETACH/DEV_REATTACH and DEV_GONE would also allow the device
to react to insertion/removal, indication with the return code if it should
be deleted completly, considered dormant (entry functions switched to
error return), or handles the state by itself completly (this would allow
a network card to keep the interfaces up, and not drop TCP connections). 

BTW. with HotPlug PCI this becomes also an issue ...

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

OOps, how do you fix fstab ??? Thats were this inforamtion is stored.

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

Are you sure it's not somewere in that CIS-page (outside the tuple space)?
You find all kinds of random data there (including ethernet addresses ...).
YMMV from acrd to card. This is not foolproof.

I was assuming a hash-function over the whole page.

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

I want to have that option, it shouldn't be mandatory.

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

Depends on your ppp configuration, having the modem come back as the
same device buys you a lot (thats just that it stays /dev/comX and not going
to /dev/comY), without any state of the modem kept. 

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

No it can't, it would require dumping the whole routing table etc. when
the card goes away and restoring it, not counting socket bound to an
(alias) address of that interface.
For stuff like flash cards keeping the device-ID is what you want (the
data will have changed anyway) but do want your falsh to comeback on 
the SAME device id, even if you plugged in a pcmcia-cdrom in the meantime.

BTW.
A lot of commercial unixes based on SVR4 now use something like
eth0-ethN for ethernet device names, where the numbering depends on when a 
device
'attached' to this pseudo-device driver. 
This would allow solve the problem in userland, but forces us to put the 
config info into user-space always.

As I stated in a previous mail, I would prefer a solution where all the
device drivers are loaded dynamicaly, but thats sometime when the 
Y2K problem is history :-)) 

Stefan

> 
> 	- Nathan

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---