lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Alan Cox writes:
> > > Dev_fs breaks completely under such circumstances you mean. Firewire and USB
> > > need potentially quite a lot of nonvolatile state storing. For that they need
> > > a daemon if they have a daemon they don't need devfs
> >
> > What state are you referring to? The permissions? And how many device
> > nodes are you talking about?
>
> Well for USB you have to remember the state of every device plugged
> into the system on a permanent basis. Not only is this needed for
> things like hot plugging when a device loses its settings as you
> move it between ports but also to ensure that when you plug it back
> in it keeps its old configuration from last use on this machine.
>
> The amount of state per device isnt really bounded, although I would
> expect it to be small. The point I was making is you do this by
> having a usb daemon sitting around getting "someone plugged this USB
> device in, its serial id is blah, its address is xyz and its a
> camera" and taking action in user space accordingly
>
> Policy in user space
>
> The pcmcia services also use this technique.
>
> So it doesnt matter if you are using devfs or not - the daemon will
> be making the device files in either and firing things up as
> needed. It has more to fire up than just devices though - insert a
> mouse - perhaps that loads gpm ?

OK, this sounds like it will be handled nicely by the devfsd I
mentioned earlier. When a driver registers a new device entry, the
daemon is notified. It can then do whatever it requires.

Regards,

Richard....

-
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.altern.org/andrebalsa/doc/lkml-faq.html

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