> From: firstname.lastname@example.org
> 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
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
> 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
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 email@example.com Please read the FAQ at http://www.tux.org/lkml/