lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [linux-usb] Re: USB device allocation
On Fri, 8 Oct 1999, Theodore Y. Ts'o wrote:

> 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.)
>
I do not like this argument at all. I have yet to see a formal
example of a case where the default permissions on a device are
inadequate for good security, and for great security permissions
alone are insufficient.

> If you need to take the USB topology into account when a device is
> plugged in, you need a user space daemon.
>
Only if the USB driver is unaware of USB topology.
A user space daemon's only information on the current
bus structure has to come from the driver. Since this
means that the driver has to be providing the daemon with
the information necessary to determine the proper device
naming, as well as registering an appropriate Major/Minor
pair for the device in question, it is conceptually simpler
to simply register the device by name directly from the
driver. Fewer steps, less possibility of having to
walk around wearing a brown paper bag.

> If you want to do something automatic based on the filesystem volume
> label, you need a user space daemon.
>
Register a device whose name is /dev/fs/label.
No daemon needed.

> 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.
>
Only if we do an insufficient job of designing devfs.
I am quite certain that it can be improved, it is the work
of few.

> 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.
>
My point is that a user space daemon is superfluous if we
can register devices by name rather than by Maj/Min pairs.

> 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?
>
Huh?
Where did this come from?
You do not need to edit files to run ppp, nor do you for minicom.
You do need to edit /etc/inittab for getty's, but you need to do
that if you want to enable logins on any device.

> 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.
>
I fail to see where devfs fails to go far enough.
It is an enabler for doing wonderful things with drivers.
No longer limited by Major/minor pairs, I can now register
/dev/mydevices/foo* and have them show up when the driver
is loaded.

Just as an example:

In working with the epca.c driver and devfs, I decided
that it would be nice if the ttyD* devices did not show
up until after the card had been initialized. So I moved
the tty registration to post-initialization. This way
when the driver was loaded and cards not initialized you
could only see the initilization device, but after running
the initialization program you had precisely the number of tty devices
registered as were initialized.
This way it was easy to see what state the cards were in, whether
the init program had been run, and whether there were any initialization
failures, all with "ls".

Of course none of this works without devfs, so I suppose
I was just wasting time...

> 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.
>
I've got a good imagination, devfs gives me a tool
that I can use to impliment things that I can imagine
more easily and elegantly than a pure userspace solution.

Daemon: select() /dev/USB/status wait...wait...
Driver: Hey! I just registered /dev/USB/modem1!
Daemon: Cool! let me tell my user about it!

> Having architected the hooks to optimize for merely populating /dev is
> ultimately a mistake.
>
Merely populating dev in a consistant and logical manner is a good
design goal. To do so in an efficient and flexible manner as well
is admirable. To throw such an artifice out because it doesn't provide
for features that are out of the realm of maintaining a sane /dev
directory is not good system architecture.

--
Daniel Taylor Senior Test Engineer Digi International
danielt@digi.com Open systems win.


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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.142 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site