[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56FBD4C3.5090701@suse.cz>
Date: Wed, 30 Mar 2016 15:29:39 +0200
From: Michal Marek <mmarek@...e.cz>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
Al Viro <viro@...iv.linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Jan Beulich <JBeulich@...e.com>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] kconfig changes for v4.6-rc1
On 2016-03-25 10:03, Geert Uytterhoeven wrote:
> On Fri, Mar 25, 2016 at 9:54 AM, Geert Uytterhoeven
>>> Al Viro (1):
>>> unbreak allmodconfig KCONFIG_ALLCONFIG=...
>>
>> I can now indeed drop the
>>
>> CONFIG_MODULES=y
>>
>> line from my
>>
>> allmod.config
>>
>> However, this fix has the side-effect of enabling CONFIG_MODULES silently for
>>
>> make allyesconfig KCONFIG_ALLCONFIG=1
>>
>> Adding an explicit
>>
>> CONFIG_MODULES=n
>>
>> to the allyes.config file fixes that.
>>
>> IMHO CONFIG_MODULES should default to y when using allmodconfig, and
>> default to n when using allyesconfig.
>
> Hmm, it seems plain "make allyesconfig" also enables CONFIG_MODULES, and
> makes many options modular. Is that intentional, especially the latter?
allyesconfig builds everything into the kernel, so why exclude the
module loader. And there are a few modules with a 'depends on m'
statement, either because this is test code in samples/ which is not
even considered when linking the kernel, or there is some "issue" when
the code is built-in. The statement might also be completely bogus, but
that's not a job of allyesconfig to decide.
Michal
Powered by blists - more mailing lists