Re: [ANNOUNCE] ndevfs - a "nano" devfs

[Mike Bell <kernel@mikebell.org>]

On Sat, Jun 25, 2005 at 04:43:05PM -0700, Greg KH wrote:
> So no, I'm not going to be submitting this.  But what it is, is a nice
> proof-of-concept for people who "just can't live without a in-kernel
> devfs" to show that it can be done in less than 300 lines of code, and
> only 6 hooks (2 functions in 3 different places) in the main kernel
> tree.  That is managable outside of the main kernel for years, with
> almost little to no effort.

Except that it isn't.

The "everything in the root" model just doesn't seem to work. It's been
so long since I used linux without devfs I hadn't thought about how
things like ALSA and the input subsystem have gone beyond supporting
device nodes in a subdirectory to actually requiring device nodes to be
in a subdirectory.

The obvious (and less important) legacy stuff has the old standard
names, but for the newer, properly named stuff like the input subsystem
and ALSA, it's just yet another incompatible naming scheme, and this one
doesn't even have the advantage of being an improvement in /dev
cleanliness like devfs tried to be.

For it to be manageable outside the mainline kernel the device names
/have/ to be inside the mainline kernel and have to be something
applications recognise without patching. When the ones in sysfs don't
work, we're back to needing the ones drivers provide through devfs
hooks, since I somehow don't see you modifying sysfs to accommodate a
project like this. :)

It's a shame too, once I had symlink, mkdir, mknod, chown/chmod and
unlink of symlinks working on the filesystem I was able to boot up with
it as /dev on my laptop, and figured it would just be a matter of
de-devfsifying my scripts, but it looks now like the names it implements
are just plain unworkable rather than merely inconvenient, quite aside
from the unholy amount of pointless chmoding required.

What could work is using the devfs-style registration hooks with a
filesystem like this, but that returns us to what I proposed (and I
believe a few people before me actually have coded up) of a simply
cleaned up and simplified devfs. Which, as far as I know, you outright
reject.