>> The major problem I see with devfs is lack of permanent permissions
>> on the nodes.
> How about /devfs nodes being symlinks to the "normal" /dev node that
> they represent?  Then the /dev nodes hold the mode bits.

(a) This moves a lot of knowledge about /dev into the kernel, where IMO
    it really doesn't belong.

(b) This totally wrecks the notion of making /dev a link farm pointing
    into a devfs mount.

Problem (b) can be addressed by providing at mount time a string that
conceptually gets substituted for "/dev/" in the above.

Thinking about this more, I've seen some more potential problems.

Let's assume that the question of how to handle devfs leaves is
settled: either make them symlinks to elsewhere or back their
permissions with a file or use an owner-and-mode translation layer or
something.

Then, how are partitions handled?  If we want, say, /dev/usr to be a
link into devfs, then we may have soemthing like

/dev/usr -> /devfs/..../:scsibus0/targ=0,lun=0:sd0/

...and what comes after that last slash?

If devfs is to be device-independent (which so far it seems it is; the
discussion seems to be talking about a devfs that is little more than a
filesystem presentation of the autoconfig device tree), where to disk
partitions fit into it?  The autoconfig code knows nothing about them,
and I am inclined to say it probably shouldn't.

The only way I see for this to work is for sd0 to be the leaf and to go
with a more generalized partitioning scheme, perhaps akin to the
labelfs that was bandied about.

That labelfs itself brings up more problems.  Suppose, for the sake of
argument, that we do

mount -t labelfs /dev/sd0 /dev/psd0

and then want to use /dev/psd0/a, /dev/psd0/b, etc.

What sort of filesystem entities are /dev/psd0/a, /dev/psd0/b, etc?
The only thing they can be, really, is device special files.  Then the
question is, what major/minor do they have?  And how does this interact
with modifying disklabels on a running system?

The only solution I see is to have a "partition" driver that is
intimately intertwined with the labelfs code.  Minors for the partition
driver would get allocated at labelfs mount time, as needed.  As for
changing disklabels, you could either allocate MAXPARTITIONS minors for
each labelfs mount or you could allocate only those that exist and then
allocate new ones as needed if/when the disklabel is changed.  The
exact minor numbers of labelfs-provided device nodes will be liable to
vary anyway, so I see no real problem with the latter - the partition
driver will have to have some kind of dynamic table anyway.

Given such a labelfs, then the partition trouble in devfs magically
evaporates, since all the device node will be is a single raw disk
device - the partition devices will arise from labelfs mounts.

> To me the main requirements for a worthwhile /devfs are:

>     1. provide a userland interface for enumerating the active
>        devices, without groveling kvm or dmesg output, or ioctl'ing
>        everything in /dev to see what doesn't return ENXIO.

The latter is useless anyway in circumstances like an install kernel,
unless you provide /dev entries in the miniroot for every possible
device, which would be *huge*...and even then it would be a probjlem
for upgrades.

But if this is what you're after, what the leaves are doesn't matter;
they could even be zero-size plain files.

>     2. provide a "stable" name for each physical device, which
>        changes as infrequently as possible given the intermediate
>        hardware layers (e.g. ISAPnP is screwed, but pure PCI is
>        golden).

For this, you need more than zero-size plain files. :-)  But there
currently is no filesystem entity that can name an entire disk device
as a whole (the RAW_PART partition is about the closest we have).  So
for these devfs nodes to be meaningful, we have to join this with a
scheme that gives us something they can meaningfully be.

This also means that devfs can't represent devices that have no device
special file nodes (network interfaces are an example), except as
something like zero-size files.

					der Mouse

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