[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-usb] Re: USB device allocation

    Theodore Y. Ts'o wrote:

    > From:
    > Date: Fri, 8 Oct 1999 14:12:07 -0500 (CDT)
    > Um, with devfs you do not need a user space daemon, so that daemon does
    > not need to keep track of all the changes to the /dev directory, which
    > promptly renders the rest of the argument irrelevent.
    > There have been a number of problems which *do* require using a user
    > space daemon. I am aware that devfs does not require a user space
    > daemon, but that's only for the simple case. In the long-term, with
    > more complex plug-and-play interfaces such as USB, I believe a user
    > space daemon will be required, and at that point, using the /devfs
    > directory as the way to communicate to the user-space daqemon is
    > inefficient.
    Just how do you think devfsd talks to the kernel? Devfsd uses the
    /dev/.devfsd device to communicate with the user-space daemon,
    something which I do not consider inefficient.. Just how efficient does
    it have to be for _you_ to consider it efficient? Should we consider
    removing /proc because you consider it inefficient?

    > For example, if you want to user/group/permissions to be properly
    > persistent across reboots, you need the user space daemon. (Or the
    > tarball on shutdown kludge.)
    For example? What does this example have to do with devfsd being
    inefficient.. It's simply stating that there are reasons one might want to
    use it.

    > If you need to take the USB topology into account when a device is
    > plugged in, you need a user space daemon.
    > If you want to do something automatic based on the filesystem volume
    > label, you need a user space daemon.
    > If you want a system which is flexible enough to handle all sorts of
    > future extensions, some of which we can't necessarily forsee right now,
    > we need a user space daemon.
    > And if we need a user space daemon, readdir() and stat() is the wrong
    > interface to get information to the daemon. That's my point.
    Yes, that would be very wrong. It's a Good Thing devfsd doesn't do this.
    Your misinformation is not welcome.

    (zinx@bliss)/tmp/zinx/devfsd$ grep "readdir" devfsd.c

    (zinx@bliss)/tmp/zinx/devfsd$ grep "stat (" devfsd.c
    if (stat (CONFIG_FILE, &statbuf) != 0)
    if (lstat (path, &statbuf) != 0)

    I fail to see how anyone who even attempted to look at devfsd could make
    this mistake.


    I would suggest to all those against devfs:
    Look at it. Look at it close. Make sure your arguements are valid.

    Zinx Verituse (finger for pgp/gpg keys)(new jul10/99)
    55*-3*\68*-+, v >

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.027 / U:87.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site