> Date: Thu, 07 Oct 1999 17:11:32 -0400
> From: Alex Nicolaou <anicolao@mud.cgl.uwaterloo.ca>
>
> 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 danielt@digi.com Open systems win.
- 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/