Sam Ravnborg wrote:
quoted text
>> I can do a more controlled comparison if you're interested.
> 
> What would be really useful would be to do some king of automated
> monitoring of the size of individual parts of the kernel in
> a few controlled configs.
> And then as son as somethings grows with > 1% for example then to
> bring this to lkml.
> Doing this based on linux-next would allow us to catch the bloaters
> while they are still or just have been doing certain changes.
> 
> It would be nice to tell someone that just enabled som new gcc option
> that this had a cost of 163.432 bytes with a certain config.
> This would get attraction and be dealt with.

This is something I've wanted to get done for the last few
years.  We've crept towards it slowly with things like bloatwatch
and some of the automated testing CELF did for it's (currently
temporarily defunct) test lab.

But we've never gotten to the last bit, which is to fully automate
the testing at the top of tree, and send notifications.  I won't
make any promises, but this is something CELF is very interested in,
and we have parts of the required software already written.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/