Re: My $0.02 on devd and devfs

Horst von Brand (vonbrand@inf.utfsm.cl)
Thu, 14 Oct 1999 08:29:24 -0300

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/