From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: [Ksummit-discuss] RFC: Kernel tinification - kernel config reduction
Date: Thu, 14 Aug 2014 11:02:21 +0200 [thread overview]
Message-ID: <CAMuHMdVQkqiE_S3ZAFziYXT4qESeofvC-6MsXfo_pYJxez2udQ@mail.gmail.com> (raw)
In-Reply-To: <53EC7839.3010704@roeck-us.net>
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
next prev parent reply other threads:[~2014-08-14 9:02 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
2014-08-14 9:02 ` Geert Uytterhoeven [this message]
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=CAMuHMdVQkqiE_S3ZAFziYXT4qESeofvC-6MsXfo_pYJxez2udQ@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux@roeck-us.net \
/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