Subject: Re: Changes for proplib to reduce kernel bloat
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Garrett D'Amore <email@example.com>
Date: 05/08/2006 19:40:04
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 <firstname.lastname@example.org> 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,
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
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191