Subject: Re: Changes for proplib to reduce kernel bloat
To: Garrett D'Amore <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 05/11/2006 16:05:13
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
> a second, you'll want it to be *fast*. In fact, Solaris does
> this with their sysevent architecture using packed "nvlists", which
> 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
> 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