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