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

[Jan Kara <jack@suse.cz>]

On Wed 13-08-14 19:29:21, 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.
  This somewhat reminds me a problem of selecting packages when
installing a distro. There you can select different "patterns", where each
pattern selects a set of packages. Then you can go and enable / disable
individual packages if you care about fine-tuning the configuration. The
patterns are like "Minimal system", "Minimal X System", "KDE Desktop",
"Office suite", ... I think we could use a similar system for Kconfig.


								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR