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

[Tim Bird <tim.bird@sonymobile.com>]

On 08/13/2014 12:19 PM, josh@joshtriplett.org wrote:
> 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.
>
> It'd be interesting to know how many of those options control the
> building of individual drivers or entire subsystems, and how many
> change kernel features in a non-trivial way.  I suspect that the latter
> set grows much more slowly, and that latter set seems like the one we
> care about limiting.
>
>> 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.
>
> I'm interested in this as well, and I planned to raise the issue of
> configuration options as part of the tinification discussion.
>
> Size-constrained systems seem likely to start from the tiniest possible
> configuration, and incrementally add specific features they need.  Given
> that, I do think we want the options for individual subsystems to look a
> lot less combinatorial and a lot closer to linear.  Several subsystems
> could likely use a major pruning of options.
>
> However, I don't think a global set of meta-options or profiles
> necessarily makes sense; either we'll end up with a large number of
> meta-configurations, or we'll end up with "sample" configurations that
> few can use unmodified.  We already have CONFIG_EMBEDDED for options
> that only exist for size purposes.

If we end up with a large number of meta-configuration options, that 
would be a failure.  In embedded, especially when fine-tuning for size,
there will likely be a need to modify the config slightly, but having
a starting point at the low end would be good.

>
> Can you elaborate a bit on the idea of "backing off" of the tiny
> configuration, and how that could work in practice?  I don't see an
> obvious way to do that with today's Kconfig; what kinds of configuration
> enhancements do you have in mind?
Well, my ideas are not well-formed yet, but I envision something where
there's a global CONFIG_TINY flag, that causes size-related options
across all sub-systems to be configured to their "small" setting.
Then, I would like to see per-sub-system options to enable configuration 
of individual options for that sub-system.  So something
like CONFIG_NET_TINY_CONFIGURABLE (name to be improved), that when
set in combination with CONFIG_TINY, still allows individual 
configuration options for networking.  Developers would need to
realize that they are re-opening the combinatorial box when they
do this.  (Note that the network maintainers might still want to limit
the configurability in their sub-system, due to e.g. readability, 
maintenance and network compatibility issues).

The idea would be that when CONFIG_TINY is not set, the options for
configuring individual bits of networking would not be visible
in 'make menuconfig' (or to automated test tools), but when
CONFIG_TINY and CONFIG_NET_TINY_CONFIGURABLE are set, they would be.

  -- Tim