> 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.

It could - go look at the partition table thread if you didn't see
what I suggested there.

 > 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.

This is another possibility.

 > 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?

In an ideal world they'd be device special files with no particularly
special major/minor, that the devfs code or labelfs code would route
off to the right place on its own.

You could also choose a major number and then allocate minor numbers
on the fly; the allocation wouldn't have to necessarily make any sense
or even be repeatable/persistent because the labelfs would make sure
the right names named the right things.

wait, that's exactly what you said.

 > 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.

Or you could build some or all of the same functionality into devfs.

 > >     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.

This is what /proc/devices in Linux does (in a limited fashion) and
that may be a better way to get at this kind of information.

Depending on what you want to do with it, of course.

-- 
   - David A. Holland             | (please continue to send non-list mail to
     dholland@cs.utoronto.ca      | dholland@hcs.harvard.edu. yes, I moved.)