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