lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-usb] Re: USB device allocation
       From: danielt@digi.com
    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.

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

    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.

    If the user plugs in a USB modem, the user knows they plugged in a modem,
    they run their getty/pppd/minicom on the new modem device.

    What's the difference between saying this and saying, "If the user plugs
    in a USB modem, they know they have plugged in a modem, and they can
    type the appropriate mknod command as root"? Why is it Too Hard and
    Unfair to force a user to type a mknod command, but it's OK to force
    them to edit /etc/ttys or /etc/ppp/options?

    I guess my ultimate problem with devfs as a design is that at the same
    time it goes too far, and yet it doesn't go far enough. It tries to do
    too much in the kernel, and as a result it locks in an interface which
    isn't the best one for doing some much more interesting a user-friendly
    breaktroughs --- breakthroughs which should be done in user space, and
    not in the kernel.

    Ideally it should be the case that a user can plug in a USB modem, and
    if the user has signed up for the easy-to-user GUI option, the user
    space daemon can pop up a wizard and ask the user whether they wish to
    use this modem for dialout or dialin access, and if it is for dialin
    access, whether pppd or login access should be provided, etc. If you
    don't like that style of interface, then you can run a different user
    space daemon which does something else. There are all sorts of things
    you can do in user space, and the flexibilty is only limited by your
    imagination.

    Having architected the hooks to optimize for merely populating /dev is
    ultimately a mistake.

    - Ted


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:3.737 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site