On Thu, Jul 31, 2008 at 06:26:16PM +0200, Thomas Petazzoni wrote: > Le Thu, 31 Jul 2008 18:37:57 +0300, > Adrian Bunk <bunk@xxxxxxxxxx> a écrit : > > > I'm just not a fan of adding config options for each few kB of code - > > we have to maintain them and the more complex the configuration > > becomes the more often it breaks. > > I'm not a fan of these too, but are there other solutions ? There are many things that can be done to reduce the kernel size or try to minimize the growth of the kernel. E.g. working on --combine -fwhole-program (where David once had preliminary patches for the per-module approach) might be better. > > What became bigger was most likely not related to the patches you > > sent. > > No, it is not. > > > Where and why did the kernel become bigger? > > It's not up-to-date with 2.6.26 and 2.6.27-rc1, but Bloatwatch > <http://www.selenic.com/bloatwatch/>, by Matt Mackall, is here to > answer these questions. I haven't made the analysis for > 2.6.26->2.6.27-rc1. It can only give some hints where to start searching. But it tracks a defconfig, and e.g. the nearly doubled size between 2.6.18 and 2.6.19 is both expected and not a problem for embedded systems. The real work is to figure out in which areas that are relevant for embedded systems the kernel became bigger. > > Why did CONFIG_FW_LOADER get enabled? > > Due to alnoconfig disabling CONFIG_EMBEDDED? > > I don't know. Haven't made the analysis for now. > > > A user will ask: > > I'm using $applications with $libraries, can I safely disable this > > option? > > Hard to tell in the general case. > > > And e.g. according to a quick grep through the sources uClibc's > > updwtmp() seems to cease working without flock(). > > Correct. But on many embedded systems, we don't care about logging past > user logins. We might even not care about logins at all. And for embedded systems with which applications is it 100% safe to disable this option? And don't answer "doesn't use flock()", I want a real-life example of a device where you could guarantee a developer that disabling this option in his product would be safe. > > It costs us maintainance of the option and the #ifdef's and gives > > users one way more to shoot themselves into the foot in nontrivial to > > detect ways. > > That's correct, and as I said previously, I fully understand the > maintainance problem of all these new configuration options. I must > admit that I do not really have more objective technical arguments that > would help us deciding whether the code size reduction vs. code > maintainance choice should be made in one direction or the other. My personal criteron for this patch is still how many real-life systems can safely disable it. > Sincerly, > > Thomas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
