On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:>On Thursday 01 May 2008 12:41, Andi Kleen wrote:Because we allowed kernel to be developed without the requirement thatTo a large extent, I agree. I certainly don't want to focus solely onNot only code size, far more important is dynamic memory consumption.
code size; there's a lot more to embedded Linux than that. But it _is_
[admittedly we right now lack a good instrumentation framework for this]
There are some cases where we really _do_ want to have CONFIG options,The problem I see is more that really nobody can even compile not alone test all these combinations anymore. Hidding the problem in inlines
but I agree that we should keep them to a minimum. And when we _do_ have
CONFIG options, they don't have to litter the actual code with ifdefs.
does not solve that. And no randconfig is not the solution either.
random config should be buildable for release kernels.
Had it been a requirement, keeping it in shape wouldn't be
too difficult.
Sure enough, _now_ fixing kernel to pass such a test on i386
would take several weeks of work at least. But it is doable.
...
On i386 it might even already work today.
But guess how much time it costs to get at least all defconfigs compiling on the other 22 architectures.
Even getting allmodconfig/allyesconfig compiling isn't trivial for all architectures, and random configurations are _far_ from compiling.
Plus the fact that you often get into situations where more options
mean complex and fragile stuff. Read the Kconfig files under drivers/media/ and check in git all commits to them since 2.6.25 alone, and you'll understand why "add an option for every bit" can result in
very high ongoing maintainance work required.
Not everything that is technically possible is also maintainable, and maintainability is a very important point in a project with several million lines changing each year.
vda
cu
Adrian