linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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