On Sat, May 24, 2008 at 01:48:15PM -0700, Andrew Morton wrote: > On Sat, 24 May 2008 22:24:27 +0200 Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: > > > > It could help to get us out of the occasional sticky situation, but it > > > does seem a bit risky. What happens with Kconfig variables which are > > > just not known about at all with some .configs? > > > > > > Silly example, one could add > > > > > > if (KCONFIG_DVB_VES1820) > > > > > > to kernel/sched.c and that would work happily until someone sets DVB=n, > > > in which case I assume KCONFIG_DVB_VES1820 doesn't get defined > > > anywhere? > > It would have helped if I had applied the correct patch... > > All boolean and tristate symbols in the konfiguration have > > their symbols defined as KCONFIG_* no matter their values. > > So KCONFIG_DVB_VES1820 would get defined. > > But there are still holes - KCONFIG_ARCH_FOOTBRIDGE wouldn't be defined > on x86, for example. Not today where we have one configuration definition per architecture. I hope we one day can change that so we have one for the whole kernel. This would for example allow us to detect when someone do a misspelled "depends on FOOBAR" because it will no longer be a normal situation to depend on unknow symbols. > Anything which is inside an `if' or inside an > if/source/endif will not be known about? I assume? These symbols would be know of - their value would just be 0. The correct patch (last one posted) does this. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
