[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.119 / U:0.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site