From: Sam Ravnborg <sam@ravnborg.org>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Steven Rostedt <rostedt@goodmis.org>,
Michal Marek <mmarek@suse.cz>, Kevin Hilman <khilman@linaro.org>,
sedat.dilek@gmail.com, Theodore Ts'o <tytso@mit.edu>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux kbuild ML <linux-kbuild@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the ext4 tree
Date: Fri, 9 Aug 2013 13:42:48 +0200 [thread overview]
Message-ID: <20130809114248.GA5691@merkur.ravnborg.org> (raw)
In-Reply-To: <20130808215449.GD3282@free.fr>
On Thu, Aug 08, 2013 at 11:54:49PM +0200, Yann E. MORIN wrote:
> Stephen, All,
>
> On 2013-08-08 21:16 +0200, Yann E. MORIN spake thusly:
> > On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> > > On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> > > wrote:
> > > >
> > > > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > > > CONFIG_MODULES unset.
> >
> > Sorry, I don't understand the above. Can you elaborate on what you did,
> > what you got, what expected, so I can try to reproduce and fix this,
> > please?
>
> Ok, I've had a look in the linux-next archives, and I think I got it.
> Is the following right?
>
> git clean -d; git clean -dX # To be sure tree is clean
> touch empty
> make KCONFIG_ALLCONFIG=empty allmodconfig
> grep MODULES .config
> $ CONFIG_MODULES is not set
>
> If so, I think I found the reason: the modules symbol is _always_ set to
> being valid as soon as KCONFIG_ALLCONFIG is read, even if it was not
> present in that file.
>
> Since it is set to be valid, the following change means it is not
> affected another value later on.
>
> So, I wonder what the best option is:
> 1- revert the following, and find another solution,
> 2- de-specialise the modules symbol,
> 3- or further specialise the modules symbol.
If we drop the special handling of "MODULES" and introduced
the following in we may fix it - hopefully:
config MODULES
option modules
The option handling is already in place. It is even documented :-)
At least we could then drop the sym_lookup here (zconf.y):
if (!modules_sym->prop) {
struct property *prop;
prop = prop_alloc(P_DEFAULT, modules_sym);
prop->expr = expr_alloc_symbol(sym_lookup("MODULES", 0));
}
Without the sym_lookup I think the symbol will not be defined and tus not marked valid.
Soory - no patch as I am busy with day-time job stuff.
Sam
next prev parent reply other threads:[~2013-08-09 11:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 1:08 linux-next: build failure after merge of the ext4 tree Stephen Rothwell
2013-07-31 1:27 ` Stephen Rothwell
2013-08-07 5:16 ` Sedat Dilek
2013-08-07 5:38 ` Stephen Rothwell
2013-08-07 5:43 ` Sedat Dilek
2013-08-07 5:59 ` Stephen Rothwell
2013-08-07 15:28 ` Kevin Hilman
2013-08-08 0:22 ` Stephen Rothwell
2013-08-08 0:36 ` Stephen Rothwell
2013-08-08 19:16 ` Yann E. MORIN
2013-08-08 21:54 ` Yann E. MORIN
2013-08-08 23:58 ` Stephen Rothwell
2013-08-09 11:42 ` Sam Ravnborg [this message]
2013-08-11 21:39 ` Yann E. MORIN
2013-08-16 13:10 ` Michal Marek
2013-08-16 17:14 ` Sam Ravnborg
2013-08-16 18:02 ` Yann E. MORIN
-- strict thread matches above, loose matches on Subject: below --
2018-10-08 23:51 Stephen Rothwell
2018-10-09 5:23 ` Theodore Y. Ts'o
2016-02-07 23:50 Stephen Rothwell
2016-01-03 23:34 Stephen Rothwell
2016-01-04 13:49 ` Theodore Ts'o
2015-07-23 0:56 Stephen Rothwell
2015-07-23 16:49 ` Theodore Ts'o
2015-07-23 17:23 ` Theodore Ts'o
2015-07-23 17:41 ` Tejun Heo
2015-05-07 1:14 Stephen Rothwell
2013-04-03 23:43 Stephen Rothwell
2013-04-04 13:18 ` Lukáš Czerner
2013-04-04 13:20 ` Theodore Ts'o
2013-04-04 13:27 ` Lukáš Czerner
2012-07-10 1:23 Stephen Rothwell
2012-07-10 1:48 ` Aditya Kali
2012-01-03 0:35 Stephen Rothwell
2012-01-05 21:06 ` Stephen Rothwell
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=20130809114248.GA5691@merkur.ravnborg.org \
--to=sam@ravnborg.org \
--cc=khilman@linaro.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=sedat.dilek@gmail.com \
--cc=sfr@canb.auug.org.au \
--cc=tytso@mit.edu \
--cc=yann.morin.1998@free.fr \
/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;
as well as URLs for NNTP newsgroup(s).