[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:

    > Date: Thu, 07 Oct 1999 17:11:32 -0400
    > From: Alex Nicolaou <>
    > My original post was meant to suggest that your proposed notification
    > method is not the right interface. There's a generic problem with the
    > UNIX fs design that there is no way to be notified when an inode
    > changes, and I think this problem could/should be fixed in a way that
    > allows any process to be notified of a change in an inode specified by
    > the application. Then you could wait for changes in /devfs or wait for
    > changes in /proc/devices and act on them. (Meanwhile GUI file managers
    > could efficiently display up-to-date directories without requiring a
    > manual refresh or wasting cycles calling readdir() repeatedly.)
    > There actually has been some talk about extending the semantics of
    > opendir() and select() so that it would be possible to select() on a
    > file descriptor returned by opendir(), so that processes could be woken
    > up when a directory has changed. (And of course, if they aren't in a
    > select/poll loop, they can always fstat() the directory and look at its
    > modtime to determine if a directory has changed.) So yes, I accept your
    > point about wanting to know if an inode (particularly a directory) has
    > changed, and there are some clean ways we can extend the traditional
    > Unix API to give us this kind of functionality (particularly with the
    > poll() interface).
    > However, even if you use this type of approach for /devfs, it's still a
    > cumbersome interface. Consider that with a /proc/devices-style
    > approach, a one or two read()'s will allow you to get all of the
    > information you need.
    > With a /devfs approach, you will still need to readdir() through all of
    > /devfs, figure out what changed, and then stat the device to see what
    > has differed. This also limits the information you can read out to what
    > is the stat()-style interface can provide, and that may not be enough to
    > give you the USB topology information. I suppose you could use
    > directories to represent USB hubs, but now you will have to recursively
    > search a directory tree to find the new devices! See what I mean? It's
    > a bad way of communicating this kind of information to the user process.
    > The advantage of /devfs is that for folks who don't care, they can
    > simply overmount /dev and be done with it. But in the long term, if you
    > accept the supposition that you *need* a user-mode daemon, /devfs is an
    > inefficient interface.
    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.

    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.

    I personally think devfsd is a major mistake. Those who do not
    use it assume that its features are limited to a set that can
    apparently be addressed with an rc script. They also assume that
    it is necessary to use devfs.

    I use devfs, I do not use devfsd.
    I gain what appear like benefits to me from using devfs without devfsd.
    I might gain even more if I were to install devfsd, I might not.

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