Kconfig: Enable Kconfig fragments to be used for defconfig
in [Kernel]
|
Prev: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
Next: Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely on 13 Jul 2010 19:20 Typo correction: 2010/7/13 Grant Likely <grant.likely(a)secretlab.ca>: [...] > <board>.Kconfig defines new board specific config items (prefixed with > "generateconfig_" which default to 'y' or 'm' and select the options > that the platform cares about. �It also then either the architecture s/either the/either includes the/ > default Kconfig, or another Kconfig fragment that includes the default > one (therefore the fragments can be 'stacked' to include, say, default > options for the architecture, or particular chipset). [...] -- 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: Grant Likely on 13 Jul 2010 19:30 On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker(a)codeaurora.org> wrote: > On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote: > >> - I haven't figured out a way for the fragment to force an option to >> � be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16". >> � This may require changing the syntax. >> - It still doesn't resolve dependencies. �A solver would help with this. >> � For the time being I work around the problem by running the generated >> � config through 'oldconfig' and looking for differences. �If the files >> � differ (ignoring comments and generateconfig_* options) after oldconfig, >> � then the <board>_defconfig target returns a failure. �(but leaves the >> � new .config intact so the user can resolve it with menuconfig). �This >> � way at least the user is told when a Kconfig fragment is invalid. > > The solver would fix the whole issues with the defconfigs , we wouldn't > need this Kconfig change .. From my perspective we shouldn't be fooling > around with anything but the solver approach .. The solver would complement Kconfig fragments, but it doesn't implement all the functionality. For instance, it doesn't help a board config picking up a bunch of options from an SoC or Architecture config file, especially things that are developer/maintainer choices as opposed to hard requirements). Solver on its own is an incremental improvement over what we currently have, but it doesn't solve the whole problem. > It just doesn't feel like Kconfig was meant to do this, it feel like > somewhat of an abuse .. Why? It uses the Kconfig language itself to specify additional constraints on the final configuration. Seems to be the essence of elegance to me. :-) 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: Grant Likely on 16 Jul 2010 14:00 On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas <catalin.marinas(a)arm.com> wrote: > On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote: >> - It still doesn't resolve dependencies. �A solver would help with this. >> � For the time being I work around the problem by running the generated >> � config through 'oldconfig' and looking for differences. �If the files >> � differ (ignoring comments and generateconfig_* options) after oldconfig, >> � then the <board>_defconfig target returns a failure. �(but leaves the >> � new .config intact so the user can resolve it with menuconfig). �This >> � way at least the user is told when a Kconfig fragment is invalid. > > It's not a solver but I'm pushing a patch to warn on selecting symbols > with unmet dependencies so that you can select further symbols (manual > solving). The patch is in linux-next but you also can grab it from: > > http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f sfr and I were talking about your patch the other day. Just warning on incomplete dependencies is enough to make it actually workable for me (without my ugly post-processing step). I was very happy to hear that it is in linux-next. Last missing piece is being able to do "select FOO = n", which Stephen is currently working on. 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: Linus Torvalds on 16 Jul 2010 14:20 On Fri, Jul 16, 2010 at 11:07 AM, Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > > I thought Linus' idea was to use: > > KBUILD_KCONFIG=file make allnoconfig See an earlier reply - that is indeed what I suggested, and yes, it avoids the need to be able to "unselect" things. However, it turns out that even then you do want to extend the Kconfig language with the ability to select particular values. Not for boolean (or even tristate things), but for things that select an integer or string value etc. So the "select OPTION=xyz" syntax ends up being a good thing even for the "-n" (allnoconfig) case too. And while I think the allnoconfig model has some advantages (the Kconfig input file ends up being independent of the default values), that very fact ends up being a disadvantage too (the Kconfig input file likely ends up being larger, since _hopefully_ the defaults are sane). So I'm not at all married to the "allnoconfig" model. It's one way of doing things, but I think the argument that we should start with the defaults and modify those instead is not an invalid one. Linus -- 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: Grant Likely on 16 Jul 2010 14:20
On Fri, Jul 16, 2010 at 12:07 PM, Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote: >> Last missing piece is being able to do "select FOO = n", which Stephen >> is currently working on. > > I thought Linus' idea was to use: > > KBUILD_KCONFIG=file make allnoconfig That was more a prototype of the idea; but it's a pretty cumbersome user interface. :-) By changing the makefile to look for kconfig fragments in the configs directory, the user interface for choosing a config remains exactly the same. As for the allnoconfig bit.... > in which case any option which would be presented to the user which hasn't > been selected by 'file' ends up being set to n. �That means there's no > need for a special "select FOO=n" construct. ....Linus chimed in on this that he doesn't actually care much. I think defconfig with an empty initial config file makes a lot more sense than allnoconfig so that we're using the default values from the normal Kconfig files. > See one of Linus' replies on June 3: > Message-ID: <alpine.LFD.2.00.1006031317410.8175(a)i5.linux-foundation.org> See this response: Message-ID: <AANLkTik-QCXFnjma3J28B9h27uajOcDhthTGz99zKgVi(a)mail.gmail.com> http://news.gmane.org/find-root.php?message_id=%3cAANLkTik%2dQCXFnjma3J28B9h27uajOcDhthTGz99zKgVi%40mail.gmail.com%3e g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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/ |