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.)
If you need to take the USB topology into account when a device is
plugged in, you need a user space daemon.
If you want to do something automatic based on the filesystem volume
label, you need a user space daemon.
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.
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.
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?
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.
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.
Having architected the hooks to optimize for merely populating /dev is
ultimately a mistake.
- 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/