On Fri, 21 Aug 1998, Stefan Grefen wrote:

> > Do we need to consider the complexity of remapping the root and swap
> > identifiers for the dynamic names?
> > 
> I don't see the problem, I would create the device-name during probe/attach
> (I know it means reading the label of a disk very early and polled). 
> Mountroot will be happy.  (this solves also the problem with scsi-id's lower
> then roots which may be there or not ...)

It isn't just a question of reading a disk. It's also a question, perhaps,
of a choice of 5 different paths via fabric logins to the same disk. I'm
also thinking that any global naming scheme can only be tentative until
the system is fully up with network interfaces running, etc.

I'm also not sure if reading a label on a volume is the best mechanism for
identifying it. But that's a different issue. Also, swap is less of a
problem in that this can usually wait until you're mostly up and running
enough of the system to identify other pieces.

The question is, what will you call the root disk in /etc/fstab? Will
it be the globally unique name or the boot name? The boot name usually
specifies how you were able to get to it from the boot prom. In OBP
namespaces this is a device tree. In BIOS name spaces, it's the BIOS
code (0x80 and above.). The global name, or the construction of it,
may be a very expensive process timewise and subsystem wise. And anyway,
you may want a root device separate from what you loaded the kernel
from.

> When would you create the device name?

That's an open question (:-)). I think as late as possible- possibly
not until open time and use a VFS to get to it.

What little time of spent lately mulling this over has me thinking
that device names should be at least be tuples of {Name,Scope,Method}
where NAME is unique within SCOPE and you use METHOD to figure
out how to access NAME within SCOPE. But this is as far as I've
really gotten with it. This is for more than disks.

Perhaps something interim would be workable, at least for disk.
For example, if you were to boot a system currently, you know via current
config methods within *BSD (if you're config file wasn't too restricted)
what your root is- you just don't necessarily have things matched within
fstab to get to it. Ditto for other disk filesystems  (nfs filesystem
semantics have the nice property of naming the end node you're trying
to get to- and care not about the path to get to it). 

Perhaps a cheezy little hack early in rc.single that builds system
unique disk identifiers (based upon the hierarchy of WWN, VPD/Inquiry
INFO, <other>, Disk Label Identifier) for all probed disks, and uses
*that* to match (with aliases for ease of use) with entities in
/etc/fstab. Or perhaps this could be a VFS mounted first with the
kernel cons'ing up the names? Would this be an acceptable first
pass?