Re: [Ksummit-discuss] RFC: Kernel tinification - kernel config reduction

[Guenter Roeck <linux@roeck-us.net>]

On Wed, Aug 13, 2014 at 07:29:21PM +0200, Bird, Tim wrote:
> I'd like to raise an issue, ahead of the kernel summit, on the topic of reducing
> kernel config options. (Or, at least, reducing the combinatorial explosion effect
> for config options).
> 
> Earlier this year when some patches were submitted to make the network
> stack more configurable, there was some pushback, due (in part) to the
> introduction of more kernel config options.
> See http://thread.gmane.org/gmane.linux.kernel/1696910
> I think it is reasonable to be concerned over the testability of myriad config
> options.
> 
> In the past, there have been efforts to curb the number of kernel config
> options, but since we now stand at about 15,000 options throughout the
> kernel, this seems like a battle we've mostly given up on.
> 
> I propose that we remove or hide a lot of the configuration options related
> to size, and instead focus on size profiles. When someone wants to build a
> minimal Linux system, they don't really want to manually trim down every
> Linux sub-system.  The more common development case is that they want
> a fully minimal Linux system, except for one or two areas where they want
> some flexibility in features.  I propose that we tie most of the options that
> are currently in the kernel for size reasons to a single or a few meta-options:
> e.g. CONFIG_SMALL, CONFIG_TINY, CONFIG_RIDICULOUS.  These
> different meta-config options can get better testing, and this will help curb
> the proliferation of size-related config options (and the resulting test
> combination explosion for those individual options.)
> 
> Note that this would be for sub-system related (feature or size) config options,
> and not driver-related config options.  Obviously, you have to have drivers
> for the hardware you plan to run on.
> 
> Optimally it would be nice to have the ability to configure a small system, and
> then "back off" of the tiny config in a particular area (say networking).
> I believe this would yield a much more tractable system for building small
> systems with Linux, than the current situation.
> 
> I'd like to discuss implementation ideas for this in the hallway track at KS.
> 
My scope, which is more focused on testing, is a bit different.

Major problem I see is that many architecture maintainers don't seem to care
about "make allmodconfig" and/or "make allyesconfig", meaning there is no
simple means to at least compile-test all code that _can_ be enabled for
a given architecture. And don't even mention "make randconfig".

Instead of CONFIG_TINY or similar, I would find it more important to get
allmodconfig and/or allyesconfig to work for as many architectures as
possible, and to create some means to help catching errors of the
kind detected by randconfig, only in a more deterministic way.

Guenter