Re: Larger dev_t

[Oliver Neukum]

> > And what would you do if the names collide ?
>
> refuse to mount - give the admin time to fix them in single user mode

That means that it could only be used for optional filesystems otherwise
booting unattended is put into question.
A user set for a practical joke could prevent booting by leaving a medium in 
the drive. You could add options for not considering removable media, etc, 
but you get to a stage where you design workarounds. That'd be bad for core 
filesystems. Thus the need for a second improved system remains.

Aside from that adding the name to /proc/partions is a good idea but not 
universally usable.

> I'm still thinking about how the root filesystem could be mounted during
> boot where devfs and /proc are not yet mounted.

Enable the kernel command line to understand devfs names.

> locate the serial number in /proc/scsi/scsi. use devfs name that
> corresponds to this device (scsi2/target 6/lun/00 or similar) and
> create a symbolic link for it. This does assume that the serial number or
> equivalent is available to be searched for. It also assumes that the

This is the problem. I wouldn't trust it.

> Is this reasonable? Perhaps not for small systems, but when lots of dynamic
> devices are available it is needed

It is reasonable. GUIs could use a unified way to learn volume names.

	Regards
		Oliver