Messages in this thread | | | Date | Fri, 8 Oct 1999 15:26:39 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
From: danielt@digi.com Date: Fri, 8 Oct 1999 14:12:07 -0500 (CDT)
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/
| |