Hi Theodore,
After merging the ext4 tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/ext4/ialloc.c: In function '__ext4_new_inode':
fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
next_ino:
^
fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
goto next_inode;
^
Hmm ...
Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
inodes in no journal mode").
I have used the ext4 tree from next-20130726 for today.
--
Cheers,
Stephen Rothwell [email protected]
Hi Ted,
On Mon, 29 Jul 2013 11:08:16 +1000 Stephen Rothwell <[email protected]> wrote:
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/ext4/ialloc.c: In function '__ext4_new_inode':
> fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
> next_ino:
> ^
> fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
> goto next_inode;
> ^
>
> Hmm ...
>
> Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
> inodes in no journal mode").
>
> I have used the ext4 tree from next-20130726 for today.
I am still getting this ...
--
Cheers,
Stephen Rothwell [email protected]
On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <[email protected]> wrote:
> Hi Theodore,
>
> After merging the ext4 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/ext4/ialloc.c: In function '__ext4_new_inode':
> fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
> next_ino:
> ^
> fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
> goto next_inode;
> ^
>
> Hmm ...
>
> Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
> inodes in no journal mode").
>
> I have used the ext4 tree from next-20130726 for today.
Since this message ext4-tree was not updated.
The commit "ext4: avoid reusing recently deleted inodes in no journal
mode" was refreshed and has a different commit-id.
Did you test with this one? You still see the breakage?
- Sedat -
[1] http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/patch/?id=533ec0ed5bac34233087f0c10c698d20095d6628
Hi Sedat,
On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
<[email protected]> wrote:
>
> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <[email protected]> wrote:
> >
> > After merging the ext4 tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/ext4/ialloc.c: In function '__ext4_new_inode':
> > fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
> > next_ino:
> > ^
> > fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
> > goto next_inode;
> > ^
> >
> > Hmm ...
> >
> > Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
> > inodes in no journal mode").
> >
> > I have used the ext4 tree from next-20130726 for today.
>
> Since this message ext4-tree was not updated.
> The commit "ext4: avoid reusing recently deleted inodes in no journal
> mode" was refreshed and has a different commit-id.
> Did you test with this one? You still see the breakage?
Today's linux-next does not have this build failure.
--
Cheers,
Stephen Rothwell [email protected]
On Wed, Aug 7, 2013 at 7:38 AM, Stephen Rothwell <[email protected]> wrote:
> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> <[email protected]> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <[email protected]> wrote:
>> >
>> > After merging the ext4 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > fs/ext4/ialloc.c: In function '__ext4_new_inode':
>> > fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
>> > next_ino:
>> > ^
>> > fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
>> > goto next_inode;
>> > ^
>> >
>> > Hmm ...
>> >
>> > Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
>> > inodes in no journal mode").
>> >
>> > I have used the ext4 tree from next-20130726 for today.
>>
>> Since this message ext4-tree was not updated.
>> The commit "ext4: avoid reusing recently deleted inodes in no journal
>> mode" was refreshed and has a different commit-id.
>> Did you test with this one? You still see the breakage?
>
> Today's linux-next does not have this build failure.
The refreshed patch is from 02-Aug-2013.
So why did next-20130805 and next-20130806 did not have it?
I was reading for these Linux-next releases the same: "I have used the
ext4 tree from next-20130726 for today.".
I am wondering what went wrong.
- Sedat -
> --
> Cheers,
> Stephen Rothwell [email protected]
Hi Sedat,
On Wed, 7 Aug 2013 07:43:59 +0200 Sedat Dilek
<[email protected]> wrote:
>
> The refreshed patch is from 02-Aug-2013.
> So why did next-20130805 and next-20130806 did not have it?
> I was reading for these Linux-next releases the same: "I have used the
> ext4 tree from next-20130726 for today.".
> I am wondering what went wrong.
Ted did not update the branch of his tree that is included in linux-next
until now. Presumably he was doing some testing - there were other
changes in it as well.
--
Cheers,
Stephen Rothwell [email protected]
Stephen Rothwell <[email protected]> writes:
> Hi Sedat,
>
> On Wed, 7 Aug 2013 07:16:57 +0200 Sedat Dilek
> <[email protected]> wrote:
>>
>> On Mon, Jul 29, 2013 at 3:08 AM, Stephen Rothwell <[email protected]> wrote:
>> >
>> > After merging the ext4 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> >
>> > fs/ext4/ialloc.c: In function '__ext4_new_inode':
>> > fs/ext4/ialloc.c:817:1: warning: label 'next_ino' defined but not used [-Wunused-label]
>> > next_ino:
>> > ^
>> > fs/ext4/ialloc.c:792:4: error: label 'next_inode' used but not defined
>> > goto next_inode;
>> > ^
>> >
>> > Hmm ...
>> >
>> > Caused by commit 4a8603ef197a ("ext4: avoid reusing recently deleted
>> > inodes in no journal mode").
>> >
>> > I have used the ext4 tree from next-20130726 for today.
>>
>> Since this message ext4-tree was not updated.
>> The commit "ext4: avoid reusing recently deleted inodes in no journal
>> mode" was refreshed and has a different commit-id.
>> Did you test with this one? You still see the breakage?
>
> Today's linux-next does not have this build failure.
However, this same commit does introduce a new build failure (not
present in next-20130806) when ext4 is built as a module:
ERROR: "dirty_expire_interval" [fs/ext4/ext4.ko] undefined!
make[3]: *** [__modpost] Error 1
make[2]: *** [modules] Error 2
The change below fixes the problem.
Found when building the mv78xx0_defconfig on ARM.
Kevin
------------8<--------------
>From 8bd28888e08124d9b298f42a0e0c3a7584ba285f Mon Sep 17 00:00:00 2001
From: Kevin Hilman <[email protected]>
Date: Wed, 7 Aug 2013 08:17:43 -0700
Subject: [PATCH] mm: page-writeback: export dirty_expire_interval, used by
ext4
commit 533ec0ed (ext4: avoid reusing recently deleted inodes in no
journal mode) started using dirty_expire_inteval, which is not
available to modules. Make it available to modules.
Cc: "Theodore Ts'o" <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
---
mm/page-writeback.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index d374b29..c8b61ef 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -104,6 +104,8 @@ EXPORT_SYMBOL_GPL(dirty_writeback_interval);
*/
unsigned int dirty_expire_interval = 30 * 100; /* centiseconds */
+EXPORT_SYMBOL_GPL(dirty_expire_interval);
+
/*
* Flag that makes the machine dump writes/reads and block dirtyings.
*/
--
1.8.3
Hi Kevin,
On Wed, 07 Aug 2013 08:28:35 -0700 Kevin Hilman
<[email protected]> wrote:
>
> However, this same commit does introduce a new build failure (not
> present in next-20130806) when ext4 is built as a module:
>
> ERROR: "dirty_expire_interval" [fs/ext4/ext4.ko] undefined!
> make[3]: *** [__modpost] Error 1
> make[2]: *** [modules] Error 2
>
> The change below fixes the problem.
>
> Found when building the mv78xx0_defconfig on ARM.
OK, this raises an interesting question for me. Why does an x86_64
allmodconfig build build ext4 (amongst lots of other things) into the
kernel (instead of making them modules)?
Well, it seems that normally it doesn't. However when I do my
x86_64 allmodconfig builds, I set
CONFIG_PROFILE_ALL_BRANCHES=n
CONFIG_DEBUG_INFO=n
CONFIG_X86_DECODER_SELFTEST=n
via the KCONFIG_ALLCONFIG=<file> mechanism and that is enough to make
sure that CONFIG_MODULES=n - which is a bit self defeating for an
allmodconfig build. :-(
In fact, even giving an empty file to KCONFIG_ALLCONFIG= is enough to
turn CONFIG_MODULES off ...
These tests were done with Linus' tree of today (head commit b7bc9e7
"Merge tag 'trace-fixes-3.11-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace").
More quick testing with an empty file: v3.9 is OK, v3.10 gives
CONFIG_MODULES unset.
--
Cheers,
Stephen Rothwell [email protected]
On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <[email protected]>
wrote:
>
> More quick testing with an empty file: v3.9 is OK, v3.10 gives
> CONFIG_MODULES unset.
Bisecting gives:
cfa98f2e0ae956feca935573e977d7661a9561b9 is the first bad commit
commit cfa98f2e0ae956feca935573e977d7661a9561b9
Author: Yann E. MORIN <[email protected]>
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" <[email protected]>
And reverting that commit in v3.10 gives me CONFIG_MODULES=y.
--
Cheers,
Stephen Rothwell [email protected]
Stephen, All,
On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell <[email protected]>
> 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?
> Bisecting gives:
>
> cfa98f2e0ae956feca935573e977d7661a9561b9 is the first bad commit
> commit cfa98f2e0ae956feca935573e977d7661a9561b9
> Author: Yann E. MORIN <[email protected]>
> 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" <[email protected]>
>
> 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. |
'------------------------------^-------^------------------^--------------------'
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 <[email protected]>
> > 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 <[email protected]>
> > 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" <[email protected]>
> >
> > 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. |
'------------------------------^-------^------------------^--------------------'
Hi Yann,
On Thu, 8 Aug 2013 23:54:49 +0200 "Yann E. MORIN" <[email protected]> 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 [email protected]
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 <[email protected]>
> > > 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
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 <[email protected]>
> > > > 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. |
'------------------------------^-------^------------------^--------------------'
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
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
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. |
'------------------------------^-------^------------------^--------------------'