Garrett D'Amore wrote:
> Is there some reason that the exchange across kernel boundaries should
> be done in a human editable format?  The only thing I can think of is to
> allow the kernel to directly read configuration data from a filesystem
> that was previously hand-edited.

That, and that it's easy to do, Jason only had to implement one
serialized form, and it requires nothing of userland code--a program
can be dumb as a post and still get readable config data from somewhere
and pass it to a kernel service.

A binary format could make the lexer smaller in the kernel, but is
really sort of moving the work around; now there needs to be userland
code to create the binary format, somebody needs to implement it in a
library, and everybody needs to link to it.

As I see it, now that proplib is there, some further ideas about it
can be handled incrementally in the usual way. For instance, I noticed
(and suggested to Jason) some ways the header size of the objects
could be economized, which could be a big win if you have lots of
small objects ... but it's nothing that needs to be done immediately,
it can be reworked at any time without visible API change, and I could
even submit a patch for it myself one day if nobody beats me to it.

Changing the serialized form used by the kernel would be more visible,
but if, say, user code by convention used the user proplib for all its
manipulations, and to serialize everything in 'kernel form' before
passing it to the kernel, that would limit the visibility of later
changing the 'kernel form'.

And whether that kind of future change is worth making could be decided
after some actual benchmarking of the code, to find just what realistic
tasks it's too slow for, and by how much, and how much better the binary
form would be. The bigger the need, the more likely someone takes the
time to code it.

-Chap