Messages in this thread | | | Date | Fri, 8 Oct 1999 22:22:33 -0500 (CDT) | From | "Forever shall I be." <> | Subject | Re: [linux-usb] Re: USB device allocation |
| |
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. 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$
(zinx@bliss)/tmp/zinx/devfsd$ grep "stat (" devfsd.c if (stat (CONFIG_FILE, &statbuf) != 0) if (lstat (path, &statbuf) != 0) (zinx@bliss)/tmp/zinx/devfsd$
I fail to see how anyone who even attempted to look at devfsd could make this mistake.
[snip]
I would suggest to all those against devfs: Look at it. Look at it close. Make sure your arguements are valid.
-- Zinx Verituse (finger @bliss.penguinpowered.com for pgp/gpg keys)(new jul10/99) pgp9FE5C9747EB8FF329BB13199C4008E67/gpg574673A12184A27A9EC0EDCCE132BCEF921B1558 0"2-1=0>0:1(2<192:0?0;0A0@2=0<0=1.0A2=0<2A0-">:#v_52*,@ 55*-3*\68*-+, v >
- 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/
| |