Messages in this thread | | | Date | Wed, 4 Jun 2008 22:24:11 +0200 | From | Jörn Engel <> | Subject | Re: [PATCH] console - Add configurable support for console charset translation |
| |
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-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/
| |