[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-usb] Re: USB device allocation

Theodore Y. Ts'o wrote:

> From:
> 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.
Just how do you think devfsd talks to the kernel? Devfsd uses the
/dev/.devfsd device to communicate with the user-space daemon,
something which I do not consider inefficient.. Just how efficient does
it have to be for _you_ to consider it efficient? Should we consider
removing /proc because you consider it 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.)
For example? What does this example have to do with devfsd being
inefficient.. It's simply stating that there are reasons one might want to
use it.

> 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.
Yes, that would be very wrong. It's a Good Thing devfsd doesn't do this.
Your misinformation is not welcome.

(zinx@bliss)/tmp/zinx/devfsd$ grep "readdir" devfsd.c

(zinx@bliss)/tmp/zinx/devfsd$ grep "stat (" devfsd.c
if (stat (CONFIG_FILE, &statbuf) != 0)
if (lstat (path, &statbuf) != 0)
I fail to see how anyone who even attempted to look at devfsd could make
this mistake.


I would suggest to all those against devfs:
Look at it. Look at it close. Make sure your arguements are valid.

Zinx Verituse (finger for pgp/gpg keys)(new jul10/99)
55*-3*\68*-+, v >

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean