> The major problem I see with devfs is lack of permanent permissions on
> the nodes.  My preferred solution to that is to provide a way to have a
> symlink whose ownership and mode bits are saved and applied to the
> targeted object, so that thus-marked symlinks can be used to provide
> such things.  (The nodes in devfs might even be mode 000 - root will be
> able to access 'em anyway; remember, this filesystem will be local.)

How about /devfs nodes being symlinks to the "normal" /dev node that they
represent? Then the /dev nodes hold the mode bits.

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.

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

"Anything else is negotiable."

Long term, I'm also looking for good device capability queries. For instance,
eject(1) currently hard-codes a bunch of known devices and their types. But
what it really wants to do is ask the device "do you support ejecting?".

A disk utility program for X would just want to ask the system "give me a
list of all disks, a list of all removable disks, a list of all ejectable
disks, a list of all cdaudio capable disks, a list of all cdrecord capable
disks, a list of all format capable disks, etc..."

It is probably not appropriate for the kernel to provide all that directly,
but it is certainly appropriate for the kernel to provide robust primitives
that could be used to accomplish such a query.

I suppose if we could eliminate all overlapping/conflicting ioctl's, then
exhaustive ioctl-groveling would be sufficient to accomplish what I have
in mind here. But I would hate to have to defend that implementation at a
user-group meeting.

Todd Whitesel
toddpw @ best.com