lkml.org 
[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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