[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-usb] Re: USB device allocation
    On Fri, 8 Oct 1999, 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.
    > 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.)
    I do not like this argument at all. I have yet to see a formal
    example of a case where the default permissions on a device are
    inadequate for good security, and for great security permissions
    alone are insufficient.

    > If you need to take the USB topology into account when a device is
    > plugged in, you need a user space daemon.
    Only if the USB driver is unaware of USB topology.
    A user space daemon's only information on the current
    bus structure has to come from the driver. Since this
    means that the driver has to be providing the daemon with
    the information necessary to determine the proper device
    naming, as well as registering an appropriate Major/Minor
    pair for the device in question, it is conceptually simpler
    to simply register the device by name directly from the
    driver. Fewer steps, less possibility of having to
    walk around wearing a brown paper bag.

    > If you want to do something automatic based on the filesystem volume
    > label, you need a user space daemon.
    Register a device whose name is /dev/fs/label.
    No daemon needed.

    > 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.
    Only if we do an insufficient job of designing devfs.
    I am quite certain that it can be improved, it is the work
    of few.

    > 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.
    My point is that a user space daemon is superfluous if we
    can register devices by name rather than by Maj/Min pairs.

    > 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?
    Where did this come from?
    You do not need to edit files to run ppp, nor do you for minicom.
    You do need to edit /etc/inittab for getty's, but you need to do
    that if you want to enable logins on any device.

    > 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.
    I fail to see where devfs fails to go far enough.
    It is an enabler for doing wonderful things with drivers.
    No longer limited by Major/minor pairs, I can now register
    /dev/mydevices/foo* and have them show up when the driver
    is loaded.

    Just as an example:

    In working with the epca.c driver and devfs, I decided
    that it would be nice if the ttyD* devices did not show
    up until after the card had been initialized. So I moved
    the tty registration to post-initialization. This way
    when the driver was loaded and cards not initialized you
    could only see the initilization device, but after running
    the initialization program you had precisely the number of tty devices
    registered as were initialized.
    This way it was easy to see what state the cards were in, whether
    the init program had been run, and whether there were any initialization
    failures, all with "ls".

    Of course none of this works without devfs, so I suppose
    I was just wasting time...

    > 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.
    I've got a good imagination, devfs gives me a tool
    that I can use to impliment things that I can imagine
    more easily and elegantly than a pure userspace solution.

    Daemon: select() /dev/USB/status wait...wait...
    Driver: Hey! I just registered /dev/USB/modem1!
    Daemon: Cool! let me tell my user about it!

    > Having architected the hooks to optimize for merely populating /dev is
    > ultimately a mistake.
    Merely populating dev in a consistant and logical manner is a good
    design goal. To do so in an efficient and flexible manner as well
    is admirable. To throw such an artifice out because it doesn't provide
    for features that are out of the realm of maintaining a sane /dev
    directory is not good system architecture.

    Daniel Taylor Senior Test Engineer Digi International Open systems win.

    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.030 / U:35.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site