On Wed, 4 June 2008 21:15:22 +0200, Sam Ravnborg wrote:
>
> 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.
I've tried that for one evening without immediate results, then got
distracted again. My basic idea was to compile a kernel, measure the
size, apply a patch, recompile and measure the new size. One could even
do something similar to git-bisect that way, each time ignoring the half
that causes less bloat.
The main disadvantage I see is with the overwhelming number of new
config options being added. Going from 2.6.x to 2.6.x+1 will add so
many new options that I usually just 'yes "" | make oldconfig'.
If someone can translate my description into a few lines of bash or
perl, we could turn it into a "make bloatcheck" and require^W hope that
at least some people use it, get ashamed and fix their mess before it
even hits the list.
Jörn
--
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
