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

["Bird, Tim" <Tim.Bird@sonymobile.com>]

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.

Thoughts? 
 -- Tim