devfs and dynamic devices

Slyglif Cain (slyglif@magerealm.com)
Sun, 9 Aug 1998 01:46:24 -0700


> From: hpa@transmeta.com (H. Peter Anvin)
> Date: 9 Aug 1998 02:17:05 GMT
> Subject: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
>
> But why having devfs at all? It seems devfs is the continual
> solution in search of a problem...

Here is a suggestion:
While I agree that dynamic creation/destruction of device nodes is a
"good thing", it appears that most of it could be done with daemons.
Perhaps the correct solution is to 1) put devfs in the kernel for now,
since it does do this, has working clean, working code, and has some
hooks which could help with a different solution in the future, and 2)
create a generic daemon (hotplugd) which will be notified on
insertion/removal of the device, and as many other parameters as is
needed. This generic daemon would then call a specific daemon for the
device type (usbd, scsid, pcmciad, 1394d, etc), and pass all of the
parameters (other then the generic device type) to this daemon which
would then create the device file, set the modes how they should be
(based on whatever rule implementation the daemon will use), start any
needed programs, and go back to sleep.

Here is the reasoning:
1) Since this currently fixes scsi device naming, is working code,
and can deal with dynamic devices, it should be put in as experimental
code for 2.2. This will then provide the basis for the dynamic
notification of all devices types that need it in the future
(/dev/null and some others probably don't need to be dynamic, but most
things should be).
2) By using a generic daemon instead of specific ones for the
kernel notification, you don't have to code any specifics into the
kernel, and you can setup hotplugd so it knows about all device types,
and you could block access to certain device types from it (usb opens
a security hole? just tell hotplugd not to pass the call on. similar
in concept to inetd). Also, by not having the kernel have to know
about all of the different daemons, it should be able to turn the
notification into a single kernel call and save on kernel memory (and
size).

=====================================================================
// Chris Giard (a.k.a. Slyglif Cain) | I find my life is a lot
// EMAIL: slyglif@magerealm.com | easier the lower I keep
// URL: http://www.primenet.com/~slyglif | everyone's expectations.
// ICQ: 4481627 | --Calvin 1992

-
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