Bill Studenmund writes:

> very messy naming issues. We seem to have two name spaces, that of nodes
> on the disk and that of devices. Sometimes the namespace for devices shows
> up, sometimes it doesn't.
> 
> Also, what happens when we rename a node? That name in the "node" space is
> now open, so we could more another device's node there. Now say there's
> symlink to that name. Does it point to the original node, or the
> newly-named node (i.e. does it point to the name at the node or at the
> device level)?
> 
> I uesd to think some idea using on-disk device nodes would work, but I
> don't anymore. Why shouldn't we just synthesize the whole thing from
> scratch?

The answer to the last question is, obviously, that we need ownership and
mode changes to be persistent.  Any solution is going to have to provide
some form of persistence for those data, with update integrity and recoverability.
The central question in this thread is the representation for the persistent
data.  Eric's suggestion was one possible representation; other suggestions
have included a text file stored beneath the mount point, and binary files
containing similar information.  Some of the tradeoffs have already been
covered.

I think you're spot on when you point out there are two namespaces.  Part
of what we need to maintain in some persistent store is the mapping between
them.  (For some devices you won't care.  But for some you will want to
assure that the same node name is reliably associated with the same device.)
That mapping will be done in the kernel or out of it (those are the two
obvious choices).  Doing it in the kernel requires making the node-name-space
visible in kernel-land, say by a suitable extension of config(9) language
that allows expressing node names.  Doing it out of the kernel, conversely,
requires making the driver-locator-name-space visible in user-land, say by
a convention for canonical locator-based names in a devfs a la Solaris.
(It was pointed out earlier that there's really a third approach, which is
to invent a third namespace like dev_t that must be mapped in both directions,
but I think we agree part of the point of a devfs is to get rid of that
complexifying layer.)

The difficulties you point out with renaming and so on are not difficulties
with any one choice of representation for the persistent owner/status data;
they will be consequences of any scheme that fails to provide a reliable way
to name things in locator-space, regardless of the concrete representation.
So it's a side issue as far as representation choice is concerned.

Cheers,
-Chap