>>> [...] is clearly the better approach.
>> It's better - in some cases.  It's also worse - in other cases.
> I think it is *always* the better approach,

As a simple example of a case where it's worse than the current
approach, "why should all of a sudden /usr fail to mount just because I
hauled a scratch disk out of my spare disk pile and connected it?  Oh
fsck, right, it had /usr from that other system on it briefly...".  Or
worse, there are disambiguating rules that choose the new disk's /usr
and "what the h311 do you mean /usr/bin is suddenly full of sun3
binaries instead of sparc binaries?!".

> however....
>> It would be a good thing to have available.  It would be an
>> extremely obnoxious thing to have no alternative to.
> I think the current existing approach offered by mount(2) is very
> much an acceptable alternative.

Then I think we are in furious agreement, lacking only

- Either decide to use the last-mounted-on string from the superblock
   or find a place to stash the filesystem label string (I see no
   reason not to go with the former)

- An interface so that mount(8) can get a list of all disks on the
   system (to go searching for filesystems on) - anyone for
   /kern/disks/? :-)

- A way to resolve ambiguities, or else decide to just error out (but
   remember that when multiple partitions begin at the same place, they
   will appear to contain the same superblock)

- A command-line syntax to mount(8) to have it find the filesystem
   device by filesystem label instead of /dev name, and a companion
   syntax for fstab

- Someone to actually implement it

I am emphatically not volunteering for any of this.  (I may implement
/kern/disks, if only because it sounds like a cool idea on its own.  If
I do I'll let it be known.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B