From: Guenter Roeck <linux@roeck-us.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] RFC: Kernel tinification - kernel config reduction
Date: Thu, 14 Aug 2014 01:50:01 -0700 [thread overview]
Message-ID: <53EC7839.3010704@roeck-us.net> (raw)
In-Reply-To: <CAMuHMdXZWhLtTzUnPymSt-P=viz7O7fq8nFaM-mHLT+XMnRJcA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-08-14 8:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 17:29 Bird, Tim
2014-08-13 18:07 ` Guenter Roeck
2014-08-13 19:53 ` Geert Uytterhoeven
2014-08-13 22:45 ` Guenter Roeck
2014-08-14 0:14 ` Mark Brown
2014-08-14 0:38 ` Guenter Roeck
2014-08-14 15:33 ` Mark Brown
2014-08-14 7:49 ` Geert Uytterhoeven
2014-08-14 16:39 ` Mark Brown
2014-08-14 7:40 ` Geert Uytterhoeven
2014-08-14 8:50 ` Guenter Roeck [this message]
2014-08-14 9:02 ` Geert Uytterhoeven
2014-08-15 11:04 ` Guenter Roeck
2014-08-14 19:57 ` Stefan Hengelein
2014-08-13 19:19 ` josh
2014-08-14 16:30 ` Tim Bird
2014-08-14 17:17 ` Josh Triplett
2014-08-14 16:03 ` Christoph Lameter
2014-08-14 18:54 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53EC7839.3010704@roeck-us.net \
--to=linux@roeck-us.net \
--cc=geert@linux-m68k.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox