Messages in this thread | | | Subject | Re: My $0.02 on devd and devfs | Date | Thu, 14 Oct 1999 08:29:24 -0300 | From | Horst von Brand <> |
| |
Andreas Bombe <andreas.bombe@munich.netsurf.de> > On Mon, Oct 11, 1999 at 04:02:28AM +0000, H. Peter Anvin wrote: > > The right solution -- which the devfs people have correctly identified > > -- is a user-space daemon. However, once you have the user-space > > daemon, "devd", I believe you neither need nor want the virtual > > filesystem, in the general case. However, I can understand that in > > some configurations (like embedded systems) it may be desirable. > > > > This is what I would like to see: > > > > * A device daemon, devd, which can add devices on demand. I was > > thinking of one which would receive data packets like the following: > > > > <stub_name, type, major, first_minor, count, naming_scheme> > > > > e.g. > > > > <"ttyS", char, 4, 64, 192, "serial"> > > I agree with you on that in general, but I would propose a different > design. Go for real simplicity. > > Base the kernel to devd interface completely on strings. The messages > have some basic rules about the start but the args are completely left > to the driver. Every message contains a descriptive driver identifying > string (avoids need for central name/number allocation instance).
Please don't leave anything "up to the driver", each one _will_ do it differently, and the resulting devd will be a complete mess. Look at the current complaints against the /proc formats.
[...]
> Drivers would need to register themselves with the kernel side of the > devd pipe for the following reason: As long as no devd is running, the > configuration information lines are simply thrown away, assuming that > drivers know their configuration anyway and can always recreate them. > As soon as a devd connects to the pipe, all registered drivers are > asked to send a snapshot of their current configuration through the > usual channels in the usual ("add") format. devd can then catch up > without doing anything special and without losing anything.
Why not make that data just stay around for anybody interested? Or just record what is currently available? -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/
| |