lkml.org 
[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-06-27 09:27    [W:3.915 / U:0.644 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site