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/