In message <87pvduwe3w.fsf@netbsd1.cygnus.com>  Chris G. Demetriou wrote:
> Stefan Grefen <grefen@hprc.tandem.com> writes:
> > 
> > Let do it NOW. Are there any objections (esp. from people deciding if it
> > goes in the tree or not, charles? jason? Chris? ... ).
> 

[..]

> I don't mind e.g. assigning logical names to devices, e.g. "root_disk"
> or similar things.  that's fine and dandy, and to be quite honest
> almost completely outside of the scope of "autoconfiguration" as it
> exists now.

I aggree :-) This mutated from general Device IDs to naming disks ...
The big question is, do we want to have Device IDs to identify a 
piece of hardware.
What we do there for each device is depends on the device.
The device ID should prevent on 'dynamic' busses that a device is 
idenified will change its name after a removal/reattachment or
that a device is identified with the same name as a different device
that has been removed. 

My reasons for this are quite simple:
    There is no way for the kernel to ensure that all references to 
	the old device name are purged when it is removed. 
    There are benefits if you can keep state around (esp. network cards)
	if you only temporarly remove a device.

I can't see another way of doing it.

> 
> However, if you're suggesting forcing targets 0-7 on controller 0 to
> be sd0-7, etc. that's totally bogus.  I, personally, have benefitted

NOOOOO, the opposite is the intention. :-)

> from the flexibility that the existing configuration mechansim
> allows.  (E.g. to set things up so that you device numbers stay the
> same even if you move your disks between SCSI chains.)  I'm sure
> others have, as well.

What this thread evoled into (from the original device ID ...) is that in 
this case the physical disk-drive is identied either by a serial number or
by a name in the disklabel.

So that regardless on which Scsi-bus and -ID this device is identified 
always with the same name. (this even without nailing it down in config).

This can be autoconfig, but for the special case of disks with labels,
there are more elegant ways to handle that (special /dev/dsk filesystem),
or a vold process (thigtly copuled to the busdriver so it sees all 
configuration changes) that creates symlinks.

Stefan

> 
> 
> cgd
> -- 
> Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
> Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
> Plug: Get your official NetBSD-1.3.2 CDROM set today! http://www.netbsd.com/

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