Messages in this thread | | | Date | Mon, 11 Oct 1999 16:14:42 -0700 (PDT) | From | David Lang <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
Ted, does the current devfsd just work by scanning the directory? or is it notified by the kernel that a new device has been registered? If it is notified by the kernel then it can do a bunch of things like you describe, if not my next question is to Richard asking if the interface can be changed.
David Lang
On Fri, 8 Oct 1999, Theodore Y. Ts'o wrote:
> Date: Fri, 8 Oct 1999 15:26:39 -0400 > From: Theodore Y. Ts'o <tytso@MIT.EDU> > To: danielt@digi.com > Cc: Theodore Y. Ts'o <tytso@MIT.EDU>, linux-kernel@vger.rutgers.edu, linux-usb@suse.com > 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/ >
- 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/
| |