kbuild: kconfig changes
in [Kernel]
|
Prev: writeback: explicit low bound for vm.dirty_ratio
Next: [PATCH 4/42 v2] drivers/infiniband/hw/nes: Adjust confusing if indentation
From: Sam Ravnborg on 7 Aug 2010 00:10 > > This change prevents some the minimal defconfig options from working. > Specifically our usb gadget drivers do not get set. Can you help me reproduce this? I have found an issue with choice values in combination with tristate logic that fails. I hope this is something similar. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arve Hjønnevåg on 7 Aug 2010 00:50 On Fri, Aug 6, 2010 at 9:01 PM, Sam Ravnborg <sam(a)ravnborg.org> wrote: >> >> This change prevents some the minimal defconfig options from working. >> Specifically our usb gadget drivers do not get set. > > Can you help me reproduce this? > > I have found an issue with choice values in combination with > tristate logic that fails. I hope this is something similar. > It is probably the same problem. The gadget driver that was not set is not buildable as a module (it is not in the mainline kernel). If I select another gadget driver instead it just gets changed to build as a module instead. If you create a file, arch/arm/configs/test_defconfig with the following: CONFIG_MODULES=y CONFIG_USB_GADGET=y CONFIG_USB_MASS_STORAGE=y then "make test_defconfig" results in .config having: CONFIG_USB_MASS_STORAGE=m (at least if you are set up to compile for arm) -- Arve Hj�nnev�g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Sam Ravnborg on 8 Aug 2010 12:00 On Fri, Aug 06, 2010 at 09:43:24PM -0700, Arve Hj?nnev?g wrote: > On Fri, Aug 6, 2010 at 9:01 PM, Sam Ravnborg <sam(a)ravnborg.org> wrote: > >> > >> This change prevents some the minimal defconfig options from working. > >> Specifically our usb gadget drivers do not get set. > > > > Can you help me reproduce this? > > > > I have found an issue with choice values in combination with > > tristate logic that fails. I hope this is something similar. > > > > It is probably the same problem. The gadget driver that was not set is > not buildable as a module (it is not in the mainline kernel). If I > select another gadget driver instead it just gets changed to build as > a module instead. > > If you create a file, arch/arm/configs/test_defconfig with the following: > CONFIG_MODULES=y > CONFIG_USB_GADGET=y > CONFIG_USB_MASS_STORAGE=y > > then "make test_defconfig" results in .config having: > CONFIG_USB_MASS_STORAGE=m > > (at least if you are set up to compile for arm) Thanks Arve. I have it reproduced now with a simple Kconfig: $ cat Kconfig config M def_bool y option modules choice prompt "choice list" config A tristate "a" config B tristate "b" endchoice $cat defconfig CONFIG_M=y CONFIG_A=y # CONFIG_B is not set If I do: $scripts/kconfig/conf --defconfig=defconfig Kconfig with the above input the resulting .config is OK. But If I drop the line: # CONFIG_B is not set in the defconfig file then I end with CONFIG_A set to m. And this is not as expected - I cannot see why it should matter if we specify the value of B or not. What we see here is that savedefconfig trigger a bug in the other part of kconfig - a bug which was not exposed before. The reason why your patch cured it was that we then no longer triggered the bug (at least I guess so I did not look to close). I will look into this as time permits. I assume the fix is simple when I find the reason. I fear it is in menu_finalize() and that part of kconfig I have not yet understood. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michal Marek on 10 Aug 2010 10:10 On 8.8.2010 17:57, Sam Ravnborg wrote: > On Fri, Aug 06, 2010 at 09:43:24PM -0700, Arve Hj?nnev?g wrote: >> On Fri, Aug 6, 2010 at 9:01 PM, Sam Ravnborg <sam(a)ravnborg.org> wrote: >>>> >>>> This change prevents some the minimal defconfig options from working. >>>> Specifically our usb gadget drivers do not get set. >>> >>> Can you help me reproduce this? >>> >>> I have found an issue with choice values in combination with >>> tristate logic that fails. I hope this is something similar. >>> >> >> It is probably the same problem. The gadget driver that was not set is >> not buildable as a module (it is not in the mainline kernel). If I >> select another gadget driver instead it just gets changed to build as >> a module instead. >> >> If you create a file, arch/arm/configs/test_defconfig with the following: >> CONFIG_MODULES=y >> CONFIG_USB_GADGET=y >> CONFIG_USB_MASS_STORAGE=y >> >> then "make test_defconfig" results in .config having: >> CONFIG_USB_MASS_STORAGE=m >> >> (at least if you are set up to compile for arm) > > Thanks Arve. > > I have it reproduced now with a simple Kconfig: > > $ cat Kconfig > config M > def_bool y > option modules > > choice > prompt "choice list" > > config A > tristate "a" > > config B > tristate "b" > > endchoice > > $cat defconfig > CONFIG_M=y > CONFIG_A=y > # CONFIG_B is not set > > > If I do: > > $scripts/kconfig/conf --defconfig=defconfig Kconfig > > with the above input the resulting .config is OK. > > But If I drop the line: > > # CONFIG_B is not set > > in the defconfig file then I end with CONFIG_A set to m. > And this is not as expected - I cannot see why it should matter > if we specify the value of B or not. > > What we see here is that savedefconfig trigger a bug in the > other part of kconfig - a bug which was not exposed before. > > The reason why your patch cured it was that we then no > longer triggered the bug (at least I guess so I did not look to close). > > I will look into this as time permits. I assume the fix is simple > when I find the reason. I'm looking into it now, but understanding the kconfig internals is not easy... Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Sam Ravnborg on 10 Aug 2010 10:30
> > > > The reason why your patch cured it was that we then no > > longer triggered the bug (at least I guess so I did not look to close). > > > > I will look into this as time permits. I assume the fix is simple > > when I find the reason. > > I'm looking into it now, but understanding the kconfig internals is not > easy... Nope... What I have understood so far... If we have a choice then the choice is represented by a symbol. symbol->def[S_DEF_USER] is set to the selected symbol. If we read all the choice values then we set: symbol->flags |= SYMBOL_DEF_USER If we have a choice where we do not have all choice_values which is the case with the minimal defconfig then the missing choice_value results in that SYMBOL_DEF_USER is not set. [See confdata:conf_read after the sym_ok label] Later in symbol.c:sym_calc_value the visibility is set to mod if we do not have all values. And therefore the coice value is set to m not y. I will look a bit more at it tonight. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |