Re: My $0.02 on devd and devfs

Andreas Bombe (andreas.bombe@munich.netsurf.de)
Thu, 14 Oct 1999 20:11:53 +0200

On Thu, Oct 14, 1999 at 08:29:24AM -0300, Horst von Brand wrote:
> 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.

The devd will not be a mess, its configuration file probably will.
devd just parses strings and acts on it as configured. As far as I can
see, different drivers need different handling anyway and therefore
different blocks in the config file.

It might of course make sense to agree on standard names for common
information (e.g. PCI card location), but I don't think any format should
be enforced without being able to imagine what flexibility could get
lost.

> [...]
>
> > 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?

Because that needs kernel memory to store the messages. Once a devd
connects that will be flushed to devd, but what if no devd turns up?
With a bit of hot plugging here and there the recorded list will get
longer and longer and you can't throw away old messages because you
might lose hardware information this way. Imagine a lot of hot
plugging add/remove that could expunge SCSI information from boot
time...

You could of course provide a way for the driver to obsolete its old
messages, but you can imagine this would turn into quite a mess. It
saves CPU time in a non critical path at the sacrifice of simplicity.

Yes, I should come up with some demo code, but the IEEE 1394 subsystem
still sucks up a lot of my work time. These are just my ideas, maybe I
will implement a devd later (it won't get into 2.3/2.4 anyway, so there
is no point in hurrying).

-- 
    Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
    http://home.pages.de/~andreas.bombe/
RSA 0x886663c9  30 EC 09 73 84 7B 55 83  C4 7A 91 D9 9D C5 4B B0
DSA 0x04880A44 72E5 7031 4414 2EB6 F6B4  4CBD 1181 7032 0488 0A44


-
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/