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

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

[Bird, Tim]

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

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

[Guenter Roeck]

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

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

[Geert Uytterhoeven]

On Wed, Aug 13, 2014 at 8:07 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> 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".

There are still architectures that don't support multi-platform kernels, which
is a requirement for good coverage.

An alternative could be to have several allmodconfig builds, one for each
subset that can't be built-in together, like

make CONFIG_SUBSET_FOO=y allmodconfig
make CONFIG_SUBSET_BAR=y allmodconfig
...

> 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.

The few allmodconfig/allyesconfig builds on
kisskb.ellerman.id.au/kisskb/matrix/ are actually not in such a bad shape.
Shall more be added?

You also only build some of the allmodconfigs?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Guenter Roeck]

On Wed, Aug 13, 2014 at 09:53:58PM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 13, 2014 at 8:07 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > 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".
> 
> There are still architectures that don't support multi-platform kernels, which
> is a requirement for good coverage.
> 
This is not about creating a working kernel, but for compile tests. I have
separate configurations to test working kernels. But I would prefer to build,
say, no more than half a dozen arm configurations instead of the 40 in my
current build list.

> An alternative could be to have several allmodconfig builds, one for each
> subset that can't be built-in together, like
> 
> make CONFIG_SUBSET_FOO=y allmodconfig
> make CONFIG_SUBSET_BAR=y allmodconfig
> ...
> 
Maybe something like 

make PCI=n allmodconfig
make GPIOLIB=n allmodconfig

which would let me disable key options selectively so I can improve compile
coverage without having to go through all configurations (or 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.
> 
> The few allmodconfig/allyesconfig builds on
> kisskb.ellerman.id.au/kisskb/matrix/ are actually not in such a bad shape.
> Shall more be added?
> 
I don't think there are any you could add, at least none which actually build.
arm:allmodconfig was quite useful, but it has been broken since 3.10 or so,
and I don't think it will ever get fixed.

> You also only build some of the allmodconfigs?
> 
Never "only". I always also build defconfig, plus at least sometimes a couple
of additional configurations (if available) to improve coverage of conditional
functionality.

Guenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On Wed, Aug 13, 2014 at 03:45:07PM -0700, Guenter Roeck wrote:

> > The few allmodconfig/allyesconfig builds on
> > kisskb.ellerman.id.au/kisskb/matrix/ are actually not in such a bad shape.
> > Shall more be added?

I can't get that site to load...

> I don't think there are any you could add, at least none which actually build.

arm64 should work most of the time - I've been building it daily and
reporting the results, it's also pretty clear of warnings which is good.
There's a couple of disappointing problems at the minute though.

> arm:allmodconfig was quite useful, but it has been broken since 3.10 or so,
> and I don't think it will ever get fixed.

Why not?

> > You also only build some of the allmodconfigs?

> Never "only". I always also build defconfig, plus at least sometimes a couple
> of additional configurations (if available) to improve coverage of conditional
> functionality.

allnoconfig is interesting too for similar reasons.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Guenter Roeck]

On Thu, Aug 14, 2014 at 01:14:50AM +0100, Mark Brown wrote:
> On Wed, Aug 13, 2014 at 03:45:07PM -0700, Guenter Roeck wrote:
> 
> > > The few allmodconfig/allyesconfig builds on
> > > kisskb.ellerman.id.au/kisskb/matrix/ are actually not in such a bad shape.
> > > Shall more be added?
> 
> I can't get that site to load...
> 
Takes forever for me, but after a minute or so I get the results.

> > I don't think there are any you could add, at least none which actually build.
> 
> arm64 should work most of the time - I've been building it daily and
> reporting the results, it's also pretty clear of warnings which is good.
> There's a couple of disappointing problems at the minute though.
> 
I don't get past

scripts/mod/devicetable-offsets.c: In function 'main':
scripts/mod/devicetable-offsets.c:190:1: sorry, unimplemented: function
profiling

This is with gcc 4.8.1 for aarch64, built from buildroot, and host gcc
4.8.2-19ubuntu1. Do I need a new/different compiler ?

> > arm:allmodconfig was quite useful, but it has been broken since 3.10 or so,
> > and I don't think it will ever get fixed.
> 
> Why not?
> 
Beats me. The longer it is broken, the more difficult it will become
to fix it, and thus less likely.

Guenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Wed, Aug 13, 2014 at 05:38:27PM -0700, Guenter Roeck wrote:
> On Thu, Aug 14, 2014 at 01:14:50AM +0100, Mark Brown wrote:

> > arm64 should work most of the time - I've been building it daily and
> > reporting the results, it's also pretty clear of warnings which is good.
> > There's a couple of disappointing problems at the minute though.
> > 
> I don't get past

> scripts/mod/devicetable-offsets.c: In function 'main':
> scripts/mod/devicetable-offsets.c:190:1: sorry, unimplemented: function
> profiling

> This is with gcc 4.8.1 for aarch64, built from buildroot, and host gcc
> 4.8.2-19ubuntu1. Do I need a new/different compiler ?

Sounds like it - I use the Linaro toolchains.

> > > arm:allmodconfig was quite useful, but it has been broken since 3.10 or so,
> > > and I don't think it will ever get fixed.

> > Why not?

> Beats me. The longer it is broken, the more difficult it will become
> to fix it, and thus less likely.

There are people who actively care about that configuration though.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Geert Uytterhoeven]

Hi Mark,

On Thu, Aug 14, 2014 at 2:14 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Aug 13, 2014 at 03:45:07PM -0700, Guenter Roeck wrote:
>> > The few allmodconfig/allyesconfig builds on
>> > kisskb.ellerman.id.au/kisskb/matrix/ are actually not in such a bad shape.
>> > Shall more be added?
>
> I can't get that site to load...

Sometimes it's slow, sometimes it's fast...

> allnoconfig is interesting too for similar reasons.

Yes, but given you can't actually boot it, it usually receives even less care
than allmodconfig.

Plus you have to band-aid various trivia, like
  - NR_IRQS being zero,
  - No CPU or platform code included, causing link errors (e.g. head.o is
    not built on m68k),
  - ...

Furthermore, allnoconfig disables CONFIG_MMU on architectures that support
nommu, which is less interesting, and thus need a KCONFIG_ALLCONFIG=
trick (I'd love to have just "make CONFIG_MMU=y allnoconfig" instead).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Thu, Aug 14, 2014 at 09:49:59AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 14, 2014 at 2:14 AM, Mark Brown <broonie@kernel.org> wrote:

> > allnoconfig is interesting too for similar reasons.

> Yes, but given you can't actually boot it, it usually receives even less care
> than allmodconfig.

Sure, but part of that is a function of people doing coverage working on
it and generally setting standards.

> Plus you have to band-aid various trivia, like
>   - NR_IRQS being zero,
>   - No CPU or platform code included, causing link errors (e.g. head.o is
>     not built on m68k),
>   - ...

That's not the case for all architectures, and TBH it seems like
something that it's reasonable to fix at least in so far as it builds
and links (assuming anyone wants to work on this for the architecutre).

> Furthermore, allnoconfig disables CONFIG_MMU on architectures that support
> nommu, which is less interesting, and thus need a KCONFIG_ALLCONFIG=
> trick (I'd love to have just "make CONFIG_MMU=y allnoconfig" instead).

That'd be nice, yes.

Another thing that's interesting to me is getting the defconfigs up to
the point where they run things like LTP well.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Geert Uytterhoeven]

Hi Günther,

On Thu, Aug 14, 2014 at 12:45 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Wed, Aug 13, 2014 at 09:53:58PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Aug 13, 2014 at 8:07 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> > 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".
>>
>> There are still architectures that don't support multi-platform kernels, which
>> is a requirement for good coverage.
>>
> This is not about creating a working kernel, but for compile tests. I have
> separate configurations to test working kernels. But I would prefer to build,

If you manage to fix the duplicate symbols due to combining multiple
single-platform configs into one kernel image, why not go to the next step
to make it actually work, if possible?

E.g. a m68k allmodconfig kernel is supposed to work (actually haven't tried
that since we fixed the 4 MiB kernel size limit to make multi_defconfig work
in the not-so-tiny new world order).

> say, no more than half a dozen arm configurations instead of the 40 in my
> current build list.

For ARM, this is (slowly) being fixed. Stay tuned for 2-3 more years ;-)

>> An alternative could be to have several allmodconfig builds, one for each
>> subset that can't be built-in together, like
>>
>> make CONFIG_SUBSET_FOO=y allmodconfig
>> make CONFIG_SUBSET_BAR=y allmodconfig
>> ...
>>
> Maybe something like
>
> make PCI=n allmodconfig
> make GPIOLIB=n allmodconfig
>
> which would let me disable key options selectively so I can improve compile
> coverage without having to go through all configurations (or randconfig).

That's doable, using KCONFIG_ALLCONFIG.

>> You also only build some of the allmodconfigs?
>>
> Never "only". I always also build defconfig, plus at least sometimes a couple
> of additional configurations (if available) to improve coverage of conditional
> functionality.

Sorry, should have said "only some of the allmodconfigs".
I noticed for e.g. m68k you build defconfig and allmodconfig (and a nommu
config), but for some other architectures only defconfig.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Guenter Roeck]

Hi Geert,

On 08/14/2014 12:40 AM, Geert Uytterhoeven wrote:

>>>
>> Maybe something like
>>
>> make PCI=n allmodconfig
>> make GPIOLIB=n allmodconfig
>>
>> which would let me disable key options selectively so I can improve compile
>> coverage without having to go through all configurations (or randconfig).
>
> That's doable, using KCONFIG_ALLCONFIG.
>
I'll play with it some more, but a quick glance (and test) suggests that I can
only use it to force a configuration option to be true, not to force it to
be false. Also, there seems to be an odd side effect.

With
	kconfig.gpio:	"CONFIG_GPIOLIB=y"
and
	kconfig.nogpio:	"# CONFIG_GPIOLIB is not set"

KCONFIG_ALLCONFIG=kconfig.gpio make allnoconfig
	causes CONFIG_GPIOLIB to be set.

KCONFIG_ALLCONFIG=kconfig.gpio make allmodconfig
KCONFIG_ALLCONFIG=kconfig.nogpio make allmodconfig
	both have the odd and at least for me unexpected effect of disabling
	CONFIG_MODULES, but do not affect CONFIG_GPIOLIB.

>>> You also only build some of the allmodconfigs?
>>>
>> Never "only". I always also build defconfig, plus at least sometimes a couple
>> of additional configurations (if available) to improve coverage of conditional
>> functionality.
>
> Sorry, should have said "only some of the allmodconfigs".
> I noticed for e.g. m68k you build defconfig and allmodconfig (and a nommu
> config), but for some other architectures only defconfig.
>
I only use 'allmodconfig' and/or 'allyesconfig' if I can be reasonably sure
that the architecture maintainers care about it. That goes back to 3.10ish
when I started the -stable-queue builds; I only added allmodconfig/allyesconfig
to the list of builds if it built when I added the architecture. I didn't check
recently if I can add some more, so I may miss a couple of architectures
which do now build.

Guenter

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

[Geert Uytterhoeven]

Hi Günther,

CC kbuild

On Thu, Aug 14, 2014 at 10:50 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 08/14/2014 12:40 AM, Geert Uytterhoeven wrote:
>>> Maybe something like
>>>
>>> make PCI=n allmodconfig
>>> make GPIOLIB=n allmodconfig
>>>
>>> which would let me disable key options selectively so I can improve
>>> compile
>>> coverage without having to go through all configurations (or randconfig).
>>
>>
>> That's doable, using KCONFIG_ALLCONFIG.
>>
> I'll play with it some more, but a quick glance (and test) suggests that I
> can
> only use it to force a configuration option to be true, not to force it to
> be false. Also, there seems to be an odd side effect.
>
> With
>         kconfig.gpio:   "CONFIG_GPIOLIB=y"
> and
>         kconfig.nogpio: "# CONFIG_GPIOLIB is not set"
>
> KCONFIG_ALLCONFIG=kconfig.gpio make allnoconfig
>         causes CONFIG_GPIOLIB to be set.
>
> KCONFIG_ALLCONFIG=kconfig.gpio make allmodconfig
> KCONFIG_ALLCONFIG=kconfig.nogpio make allmodconfig
>         both have the odd and at least for me unexpected effect of disabling
>         CONFIG_MODULES, but do not affect CONFIG_GPIOLIB.

Strange...

I also saw strange things with randconfig, needing config input during the
subsequent build, or "make oldconfig" asking new questions, just after
having done a randconfig.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Guenter Roeck]

On 08/14/2014 02:02 AM, Geert Uytterhoeven wrote:
> Hi Günther,
>
> CC kbuild
>
> On Thu, Aug 14, 2014 at 10:50 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 08/14/2014 12:40 AM, Geert Uytterhoeven wrote:
>>>> Maybe something like
>>>>
>>>> make PCI=n allmodconfig
>>>> make GPIOLIB=n allmodconfig
>>>>
>>>> which would let me disable key options selectively so I can improve
>>>> compile
>>>> coverage without having to go through all configurations (or randconfig).
>>>
>>>
>>> That's doable, using KCONFIG_ALLCONFIG.
>>>
>> I'll play with it some more, but a quick glance (and test) suggests that I
>> can
>> only use it to force a configuration option to be true, not to force it to
>> be false. Also, there seems to be an odd side effect.
>>
>> With
>>          kconfig.gpio:   "CONFIG_GPIOLIB=y"
>> and
>>          kconfig.nogpio: "# CONFIG_GPIOLIB is not set"
>>
>> KCONFIG_ALLCONFIG=kconfig.gpio make allnoconfig
>>          causes CONFIG_GPIOLIB to be set.
>>
>> KCONFIG_ALLCONFIG=kconfig.gpio make allmodconfig
>> KCONFIG_ALLCONFIG=kconfig.nogpio make allmodconfig
>>          both have the odd and at least for me unexpected effect of disabling
>>          CONFIG_MODULES, but do not affect CONFIG_GPIOLIB.
>
> Strange...
>
> I also saw strange things with randconfig, needing config input during the
> subsequent build, or "make oldconfig" asking new questions, just after
> having done a randconfig.
>

I made some progress. The following KCONFIG_ALLCONFIG file lets me disable GPIOLIB
with x86_64, and still build everything as modules.

# CONFIG_FB_VIA is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_GPIOLIB is not set
CONFIG_MODULES=y

I had to deselect everything which explicitly selects GPIOLIB. Kind of makes sense.
For some reason it is necessary to specify "CONFIG_MODULES=y" even with "allmodconfig"
when using a KCONFIG_ALLCONFIG file.

Guenter

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

[Stefan Hengelein]

 > "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".

We [1] develop a tool (called 'vampyr'), which ships the desired 
functionality of compile-testing source code.
The Vampyr inspects the CPP blocks of a given source file and creates 
one or more  configurations to maximize the code coverage.  Once the 
configurations are generated, Vampyr triggers the compilation process on 
the given source files and reports compiler issues (i.e., warnings and 
errors) to the user.
Furthermore, Vampyr offers an interface to specify compilers to allow 
cross-compilation for other architectures such as ARM or MIPS. Note that 
Vampyr expands the configurations with "KCONFIG_ALLCONFIG=file.config? 
make allyesconfig", where  'allyesconfig' can be altered with the Vampyr 
interface (e.g. to 'allnoconfig'). On the current Linux HEAD the tool 
reaches a code coverage of 83 percent, whereas a plain "make 
allyesconfig" covers 64 percent of the source code [5]. You can find 
further information about the tool in a recently published paper on 
USENIX'14 [2].


 > Furthermore, allnoconfig disables CONFIG_MMU on architectures that 
support
 > nommu, which is less interesting, and thus need a KCONFIG_ALLCONFIG=
 > trick (I'd love to have just "make CONFIG_MMU=y allnoconfig" instead).

If you want to forcefully set specific features to be always off or 
always on, you can specify an additional whitelist and/or a blacklist.

For more information check out [3] or download the tarball containing 
the tool here [4].
If you have questions or desire more information about the tool, feel 
free to contact us.

Best Regards,
  Andreas Ruprecht, Valentin Rothberg, Stefan Hengelein

[1] https://www4.cs.fau.de/Research/CADOS/
[2] https://www4.cs.fau.de/Publications/2014/tartler_14_usenix.pdf
[3] http://vamos.informatik.uni-erlangen.de/trac/undertaker/wiki
[4] http://vamos.informatik.uni-erlangen.de/files/undertaker-1.5.tar.xz
[5] 
https://vamos.informatik.uni-erlangen.de/jenkins/job/vamos-linux-expansion-stats-weekly/103/artifact/expansion-bigtable.pdf 
user: public pw: i4guest

PS: Another interesting tool (unfortunately it's still in development) 
may be 'undertaker-checkpatch', which can be used to check Git commits 
for #ifdef-related bugs. We are planning to enhance this tool to run a 
Vampyr compile-test analysis on affected files.

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

[josh]

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.

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?

- Josh Triplett

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

[Tim Bird]

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

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

[Josh Triplett]

On Thu, Aug 14, 2014 at 09:30:19AM -0700, Tim Bird wrote:
> 
> 
> 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.

In general, I'd hope that starting point is "make allnoconfig", or
alternatively the new "make tinyconfig" I just posted patches for.

> >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.

Interesting idea.  Something like this:

config SUBSYSTEM_SIZABLE_FEATURE
    prompt "..." if SUBSYSTEM_TINY_CONFIGURABLE
    default !TINY
    depends on SUBSYSTEM

I could see that working.  Changing a pile of "default y" to "default
!TINY" does seem quite appealing.  However, rather than
SUBSYSTEM_TINY_CONFIGURABLE, I wonder if it would help to make Kconfig
explicitly distinguish between explicitly enabled/disabled options and
default options, or provide a script that strips a config down to only
the non-default options?  That would allow configuration with very few
non-default options to remain very short, while large configurations
would indicate significant deviation from the defaults.  For instance,
turning on TINY would add one line, and turning off an entire subsystem
would add one line, while turning on a subsystem and changing numerous
options would add many lines.

- Josh Triplett

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

[Christoph Lameter]

On Wed, 13 Aug 2014, Bird, Tim wrote:

> 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

Yes exactly.

> 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.)

I'd be interested to configure minimally sized systems in order to
increase performance. The cache footprint determines performance these
days so a tinyfication project will have performance implications as well
and has the potential to significantly speed up key kernel functionality.

> 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.

That could be useful also to come up with high performant kernels for
special functionality. Come up with a tiny config and then add config
options to enable only what is needed.

Reminds me of what Gentoo is doing

> I'd like to discuss implementation ideas for this in the hallway track at KS.
>
> Thoughts?

Get a room instead of the hallway?

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

[Jan Kara]

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