On May 11, 2006, at 3:41 PM, Garrett D'Amore wrote:

> A binary format was what I had in mind when I made my suggestion  
> that we
> *might* want to consider an alternative to the current
> format-that-looks-like-XML-but-is-really-just-a-strict-subset. :-)  If
> apple has a nice one ready to use, then I can see no reason to invent
> another one.

I will investigate this some more.

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

One of the reasons for doing this whole exercise is to make LKMs  
easier to support.  Right now, you have to compile cfdata tables with  
the C compiler.  Dumb.  I'd rather just load a plist into the kernel  
and let it digest that.  Now, it's convenient for drivers to have XML  
plists, but if the kernel lacks a way to gobble them up, then they  
need to be converted to binary plists.  Fine, the LKM loader could do  
that, but that's an extra step in userland that would not have  
otherwise been required.

You could just have both parsers in the kernel, but that kind of  
defeats the purpose, eh?

> But, I perceive that the drawback to such might be larger kernels,
> larger data sizes (assuming a binary representation would be more
> compact) and longer run times encoding/decoding the data, in what
> *might* be some time sensitive loops.  (As an example, I imagine using
> "packed" plists as a way to exchange generalized event notifications
> across a kernel/user boundary.  If you have a number of these  
> happening
> a second, you'll want it to be *fast*.  In fact, Solaris does  
> precisely
> this with their sysevent architecture using packed "nvlists", which  
> are
> similar in some ways to plists.)
>
> If I had a vote, I'd vote for a compact binary representation in the
> kernel (and across the kernel boundary), and tools in userland to help
> manipulate/convert them.  (I'm not sure I have a vote, but I can  
> express
> my opinion, can't I? :-)

The tool to convert them would simply be proplib itself -- a flag to  
decide that output format to use, and auto-detection on ingest.

Simple enough, if it really buys much.  For prop_data_t, yah you  
avoid the base64 step, and for prop_string_t, you avoid the encode step.

I will investigate the Apple binary plist format a little more and  
follow up.

-- thorpej