Bill Studenmund wrote:
> On Sun, May 07, 2006 at 04:40:50PM +0000, Christos Zoulas wrote:
>   
>> In article <20060507155425.GA3820@thoreau.thistledown.com.au>,
>> Simon Burge  <simonb@wasabisystems.com> wrote:
>>     
>>> The patch below removes the XML conversion support from proplib when
>>> it's built for the kernel, for which I can see no obvious use.  With
>>> this patch, we get rid of a good chunk of the kernel bloat that new
>>> proplib adds.  For an evbppc/WALNUT kernel the sizes before proplib,
>>> with normal proplib, and with proplib with no XML import/export
>>> functionality are:
>>>
>>> 	   text    data     bss     dec     hex filename
>>> 	3837324  452840  232444 4522608  450270 netbsd.devprop
>>> 	3856516  452968  234288 4543772  45551c netbsd.proplib
>>> 	3843576  452880  233888 4530344  4520a8 netbsd.no-xml-proplib
>>>
>>> Anyone have any problems with applying this patch?
>>>       
>> I think having the choice to compile it in or not is good (for size challenged
>> machines), but I can see a use of the XML code in the kernel such as
>> passing configuration properties between the kernel and userland via ioctl.
>>     
>
> The problem with droping the "bloat" is that we then have no way to pass 
> property lists in and out of the kernel. So whatever features come to 
> relie on this won't work for the shrunken kernels.
>
> Also, someone may opt for other parameter passing methods, just so they 
> would continue to work with a "shrunken" kernel. We then would end up 
> with TWO systems doing the same thing, which I think would be worse.
>
> Take care,
>
> Bill
>   

I'd be interested in seeing a better break down of the "bloat".  We're
only talking ~20k here.  Yes I know every bit is precious, but how much
can we prune this and *retain* _any_ common format for data passing?

I have done some work with something like this, using Solaris nvlists,
and with a home-grown solution as well.  Perhaps instead of XML we could
use some binary "fixed format" kind of representation.  It might save a
few bytes in the encoding/decoding and would probably run a bit faster. 
But how much of that 20k would we reclaim?  And the penalty would likely
be exchanging a format that can be edited with vi (and validated using
existing e.g. XML tools) with some new binary format which would
probably need another set of special tools to edit directly.  Assuming
(optimistically) that we can reclaim 15k, is it worth the functionality
loss?

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191