I *know* I should never have gotten involved in this.

On Fri, 21 Aug 1998, Stefan Grefen wrote:

> In message <Pine.GSO.3.95.980820203749.4807A-100000@jericho>  "Eduardo E. Horvath" wrote:
> > 
> 
> [...]
> 
> > Sounds good?  Well, there are some problems.  Don't quiesce your root disk
> > or you can easily hang your machine.  And keeping track of what devices
> 
> Make the tool smarter, and keep it running (and pinned) in case you hit the 
> bus where the rootdisk lives. 

I'm not suggesting that this is an intractible problem.  But it is a BIG
problem and solutions for one aspect of it do not work well for other
aspects.

> > are plugged in where on a system of any size is a nightmare, since you
> > never know what physical slot your controller number 1 is plugged into.
> > Or is it an on-board device?
> 
> Thats why I want device ID's which are unique. On a disk it can be the
> label or a serial-number if you can read it. This would make the same
> device appear always as the same ID (very handy with removable medias too).

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.

> > I strongly recommend deciding what you want to do about device naming
> > before embarking on dynamic configuration.  It's really annoying when sd3a
> > which has your root partition on it suddenly changes and becomes sd2a
> > because one of the other disks did not come up.  And Wiring it down in the
> > kernel config file is useless because, since it's a fully dynamic kernel,
> > none of the devices are in the kernel config file.  
> 
> 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.

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.

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