Subject: Re: Generic Properties
To: None <eeh@netbsd.org>
From: John Fremlin <vii@users.sourceforge.net>
List: tech-kern
Date: 06/24/2001 21:02:04
eeh@netbsd.org writes:
> Why not recycle those good old tried and tested favorites, like read(2)
> and write(2)? Then all your users need is a working shell.
>
> These are not really supposed to be manipulated from userland. The
> primary purpose of this is for communication between various parts
> of the kernel, hence the interface are designed for efficient use
> inside the kernel. Userland access is of secondary, or even
> tertiary importance.
?? Sorry for butting in orignally, I seem to have got the wrong end of
the stick. Could you give some examples of the kind of use you were
imagining?
> For the most part, the data stored in properties is in a binary
> format, so you need to process it to make it human-readable.
True (but IMHO it's not a problem).
[...]
> Also, since this is primarily designed for communication between
> different modules in the kernel,
Sort of microkernel? Or CORBA in kernel?
[...]
> A filesystem does have some advantages in this case. But a
> filesystem must be mounted to be useful.
Indeed but you can mount it easily.
> Not to mention the fact that the property heirarchy does not really
> lend itself to a filesystem tree layout.
Hmm.
> And different databases would want to be mapped to different
> structures. A device database would want to be tree-structured, by
> device node.
Sounds rather filesystem tree to me . . .
> A routing database would want to be a big table.
So your directory has lots of entries, but that shouldn't be a
problem. . .
> The generic properties infrastructure has no knowledge of the
> structure of the underlying data layout.
(Perhaps you should change it then, always good to keep structure)
> Now, one thing I had considered is to make create a device node and
> use ioctl(2)s to access the database,
How perfectly revolting!
> much like openprom handling is done. The problem with this scheme
> is that you really would want one device node for each separate
> database, and since databases can be created dynamically, this would
> quickly become difficult to maintain in a consistent manner.
(A filesystem does not have these problems)
--
http://ape.n3.net