In message <Pine.GSO.3.95.980821091343.5035C-100000@jericho>  "Eduardo E. Horvath" wrote:
> 
> I *know* I should never have gotten involved in this.

:-)

> 
> On Fri, 21 Aug 1998, Stefan Grefen wrote:

[...]

> 
> You do not want to track device by serial number.  One of the purposes of
> this is to be able to replace a broken device by an identical one that
> works.  If you use serial numbers then the new disk I plugged in to
> replace the old one that failed, that has exaclty the same information on
> it as the old one, has a different device ID and device node.  My fstab is
> now useless.

Just to get the context back, What I want is a unique device-ID for each
device (network-card, disk, etc.) so that a removed and reattached device
can be identified. The Scsi bus was just an example, which is wider used
than PCMCIA or USB.
The method for getting the unique ID will vary from device to device and
a lot of devices may not be able to generate one (like com or the keyboard).
The serial number may be handy for a TapeDrive, on a disk I would prefer
a label to name it.

> > 
> > You still have a config-file somewhere, so it is possible to nail it down,
> > (also on solaris), but there is a need for identifying dynamic devices on
> > all busses that 'allow' dymanic configuration, (pcmcia,usb,scsi, hot-swap pci,
> > ... ).
> > Thats why I think we should add a function to devsw for 'extended' device
> > configuration, which allows the kernel to interogate the device for
> > a indentification-ID, which should be unique. All other rarely used options
> > can go there too (we could overload ioctl, but must driver assume that it comes
> > with a process-context, eg. they can sleep, so it's not a 'clean' solution).
> 
> If you start with a partial solution for one type of device someone will
> try to extend it to other device types and it just won't work right.

Thats why my proposoal was to use an opaque N byte array as the indentifier
so that the kernel can identify a device when its reattached. There is no
need to export that name to userland, as this is only valid till the next
reboot.  It just ensures that if you reconnect the device (even with 
changed properties (SCSI-ID or PCMCIA-slot) it will be reattached or
if a different device comes in with the same properties, it will be
given a different name.

Makeing this persistant is another step, and using diskname by label may
be another thing altogether. I'm not sure it would  the right thing in
this context.

> 
> The other thing to keep in mind with reading configuration files on boot
> is that if the config file is trashed you're pretty much dead.  If that
> happens with Solaris you need to reinstall the OS from scratch because
> even single user mode doesn't work and you need to be an expert on the
> boot process to create the machine maintained files that were lost.

I thought so too, but on Solaris you can specify an alternate file (like
an alternate kernel on NetBD) which is used, and if this file is /dev/null
it reconstructs the file. 
We don't have to copy the bad fallback policies too :-)) 
On Unixware the file to trash is the resmgr in /stand :-))

Stefan
used
> 
> =========================================================================
> Eduardo Horvath				eeh@one-o.com
> 	"I need to find a pithy new quote." -- me
> 

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