Messages in this thread | | | Date | Mon, 27 Jun 2005 00:19:08 -0700 | From | Mike Bell <> | Subject | Re: [ANNOUNCE] ndevfs - a "nano" devfs |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |