> >> If devfs is to be device-independent [...], where [do] 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.
 > 
 > What I recall seeing there works well only when disklabels don't change
 > at run-time.  Imagine ejecting a zip disk with am MBR partition table
 > on it and popping in one with a NetBSD label - you have to detach the
 > "fdisk* at sd?" attachments corresponding to it and create "dk* at sd?"
 > attachments for the new disk.

$^#$%@#$!

although, what happens with pcmcia support when you plug in new
devices? Presumably, either the system can be made to reprobe parts of
the configuration... or it needs to gain this ability at some point
anyway.

 > And what if there's a BSD label in one of those MBR partitions?  All of
 > a sudden the autoconf tree ends up having to support a whole lot of
 > stuff that it never has had to, and it has to have tie-ins to anything
 > that can modify a disk label, including the disk read/write routines.

Well, you can demand that someone explicitly trigger a reprobe after
updating the disklabel. Or you can put part of the disklabel editing
support in the disklabel driver, which is in a certain sense the right
thing to do but kind of wasteful since it's rarely ever used.

 > Not that this is necessarily *wrong*.  But it "feels ugly" to me in a
 > way that the labelfs suggestion I gave doesn't.

True, but the labelfs thing isn't any different really; it just begs
the question in the same way that the question of mounting the fs on a
removable volume is begged.

 > >> mount -t labelfs /dev/sd0 /dev/psd0
 > >> What sort of filesystem entities are /dev/psd0/a, /dev/psd0/b, etc?
 > > 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.
 > 
 > But the labelfs code doesn't get control.  The vfs layer gets asked
 > what kind of object (say) /dev/psd0/a is, and it has to pass back
 > something.  If it passes back a device special file (and I can't think
 > of anything else it could usefully pass back), then I *think* it is out
 > of the loop thereafter; it's the driver for the major number of the
 > device that gets the call if the thing is to be opened.

I would describe this as a mistake in the VFS layer, in the long term,
and one that's not hard to fix - you ought to be able to hand back
things that look like device special files to the user but are
interpreted by the filesystem.

 > >>> 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.
 > 
 > I don't use Linux and AFAIK have no docs on what /proc/devices is.  Can
 > you describe it?

It's a kernel-generated text file that contains a table of device
drivers and major numbers, along the lines of

block
hd    3

char
tty   5

or whatever they are. It doesn't have minor numbers or non-/dev
entities, because that's not what it was for(*), but one could imagine
a similar sort of thing that did.

(*) what it was actually for was assigning major numbers on the fly
instead of hardwiring them, but that proved to be a Very Bad Idea(TM)
without a devfs.


While we're talking about features, one of the things I've wanted to
see for years (though I've never been sure how to accomplish it) is
opening devices with arguments. I liked how AmigaDOS let you open
things like "ser0:9600/n/8/1", and often thought some feature like
this would cut down a lot on clutter in /dev.

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