Re: linux-next: build failure after merge of the ext4 tree

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

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.

I'd be inclined to go for 1, but I have no straightforward idea so far.
It's late here, so I'll look more thouroughly this WE.

> > Bisecting gives:
> > 
> > cfa98f2e0ae956feca935573e977d7661a9561b9 is the first bad commit
> > commit cfa98f2e0ae956feca935573e977d7661a9561b9
> > Author: Yann E. MORIN <yann.morin.1998@free.fr>
> > Date:   Wed Apr 24 22:00:04 2013 +0200
> > 
> >     kconfig: do not override symbols already set
> >     
> >     For randconfig, if a list of required symbols is specified with
> >     KCONFIG_ALLCONFIG, such symbols do not "have a value" as per
> >     sym_has_value(), but have the "valid" flag set.
> >     
> >     Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> > 
> > And reverting that commit in v3.10 gives me CONFIG_MODULES=y.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: linux-next: build failure after merge of the ext4 tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

Hi Yann,

On Thu, 8 Aug 2013 23:54:49 +0200 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>
> 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

Yes, that is what I am seeing.

> 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.
> 
> I'd be inclined to go for 1, but I have no straightforward idea so far.
> It's late here, so I'll look more thouroughly this WE.

Thanks.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: build failure after merge of the ext4 tree

[Sam Ravnborg]

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

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

Sam, All,

On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> 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 :-)

Yes, indeed, that one is pretty easy! :-)

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

Sorry, I don't understand what we should do here.

From what I understand, here's what happens:
  - there's no symbol that declared the 'modules' option, so the
    modules_sym->prop is NULL;
  - so we look for the symbol 'MODULES' and use that as the symbol used
    to evaluate if tristates are enabled.

So, now we have 'option modules' added to MODULES, we never enter this
if() condition.

But what would happen to other projects that do not have a symbol set
with 'option modules' and no 'MODULES' symbol? Surely, those projects do
not need tristates, but what should the code do in this case?

So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.

> Soory - no patch as I am busy with day-time job stuff.

I hope you can share some guidnce here, please... ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: linux-next: build failure after merge of the ext4 tree

[Michal Marek]

On 11.8.2013 23:39, Yann E. MORIN wrote:
> On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
>> 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 :-)
> 
> Yes, indeed, that one is pretty easy! :-)
> 
>> 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.
> 
> Sorry, I don't understand what we should do here.
> 
> From what I understand, here's what happens:
>   - there's no symbol that declared the 'modules' option, so the
>     modules_sym->prop is NULL;
>   - so we look for the symbol 'MODULES' and use that as the symbol used
>     to evaluate if tristates are enabled.
> 
> So, now we have 'option modules' added to MODULES, we never enter this
> if() condition.
> 
> But what would happen to other projects that do not have a symbol set
> with 'option modules' and no 'MODULES' symbol? Surely, those projects do
> not need tristates, but what should the code do in this case?
> 
> So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.

If the Kconfig files do not provide any symbol with 'option modules',
then set modules_sym to a dummy bool with the value 'n'?

Thanks,
Michal

Re: linux-next: build failure after merge of the ext4 tree

[Sam Ravnborg]

On Fri, Aug 16, 2013 at 03:10:38PM +0200, Michal Marek wrote:
> On 11.8.2013 23:39, Yann E. MORIN wrote:
> > On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> >> 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 :-)
> > 
> > Yes, indeed, that one is pretty easy! :-)
> > 
> >> 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.
> > 
> > Sorry, I don't understand what we should do here.
> > 
> > From what I understand, here's what happens:
> >   - there's no symbol that declared the 'modules' option, so the
> >     modules_sym->prop is NULL;
> >   - so we look for the symbol 'MODULES' and use that as the symbol used
> >     to evaluate if tristates are enabled.
> > 
> > So, now we have 'option modules' added to MODULES, we never enter this
> > if() condition.
> > 
> > But what would happen to other projects that do not have a symbol set
> > with 'option modules' and no 'MODULES' symbol? Surely, those projects do
> > not need tristates, but what should the code do in this case?
> > 
> > So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.
> 
> If the Kconfig files do not provide any symbol with 'option modules',
> then set modules_sym to a dummy bool with the value 'n'?
This is my thinking too - to use the symbol "n".
But I wanted to try it out - but so far have not had time for it.

	Sam

Re: linux-next: build failure after merge of the ext4 tree

[Yann E. MORIN]

Sam, Michal, All,

On 2013-08-16 19:14 +0200, Sam Ravnborg spake thusly:
> On Fri, Aug 16, 2013 at 03:10:38PM +0200, Michal Marek wrote:
> > On 11.8.2013 23:39, Yann E. MORIN wrote:
> > > On 2013-08-09 13:42 +0200, Sam Ravnborg spake thusly:
> > >> 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 :-)
> > > 
> > > Yes, indeed, that one is pretty easy! :-)
> > > 
> > >> 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.
> > > 
> > > Sorry, I don't understand what we should do here.
> > > 
> > > From what I understand, here's what happens:
> > >   - there's no symbol that declared the 'modules' option, so the
> > >     modules_sym->prop is NULL;
> > >   - so we look for the symbol 'MODULES' and use that as the symbol used
> > >     to evaluate if tristates are enabled.
> > > 
> > > So, now we have 'option modules' added to MODULES, we never enter this
> > > if() condition.
> > > 
> > > But what would happen to other projects that do not have a symbol set
> > > with 'option modules' and no 'MODULES' symbol? Surely, those projects do
> > > not need tristates, but what should the code do in this case?
> > > 
> > > So, I don't know what to replace this 'sym_lookup("MODULES", 0)' with.
> > 
> > If the Kconfig files do not provide any symbol with 'option modules',
> > then set modules_sym to a dummy bool with the value 'n'?
> This is my thinking too - to use the symbol "n".
> But I wanted to try it out - but so far have not had time for it.

OK, I'll tackle this. Thanks for the info. :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'