| Message ID | 1299637966-18458-2-git-send-email-john.stultz@linaro.org |
|---|---|
| State | Deferred |
| Headers | show |
On Wednesday 09 March 2011 03:32:35 John Stultz wrote: > In looking at trying to replace defconfigs with kconfig fragments, > one limitation identified is that config items in choice blocks > cannot be selected by other config options. > > One way to doge this would be to create non-visible meta options > that change the choice block's default, but that would require > additional meta-configs per-choice config, plus a conditional > default per meta-config. That just seemed too ugly. > > So I looked into how to allow the choice default to be overrided > by a select statment, and the following patch is the result. > > I'm very new to kconfig code, so I expect that my changes are > probably broken in some subtle way, but in my testing it seems > to work. The select only chagnes the default, which can be overrided > by the user via the menu. This allows kconfig fragments to work > for make defconfig, while not restricting user customization. > > Thoughts and feedback (or alternate approaches) would be appreciated. > > thanks > -john > > CC: Grant Likely <grant.likely@secretlab.ca> > CC: Jason Hui <jason.hui@linaro.org> > CC: patches@linaro.org > Signed-off-by: John Stultz <john.stultz@linaro.org> The patch looks fine to me (as far as my little Kconfig knowledge goes). Two comments about the submission form though: * Ideally, the initial description is split into two parts: one that is suitable as a changelog and the other that is your personal comment, including the "thanks" part, and put it below the --- line, so that git can automatically cut it. * I think you should also Cc the Kconfig maintainer, Roman Zippel <zippel@linux-m68k.org>, and linux-kbuild@vger.kernel.org. Arnd
On Wed, Mar 9, 2011 at 1:38 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Wednesday 09 March 2011 03:32:35 John Stultz wrote: >> In looking at trying to replace defconfigs with kconfig fragments, >> one limitation identified is that config items in choice blocks >> cannot be selected by other config options. >> >> One way to doge this would be to create non-visible meta options >> that change the choice block's default, but that would require >> additional meta-configs per-choice config, plus a conditional >> default per meta-config. That just seemed too ugly. >> >> So I looked into how to allow the choice default to be overrided >> by a select statment, and the following patch is the result. >> >> I'm very new to kconfig code, so I expect that my changes are >> probably broken in some subtle way, but in my testing it seems >> to work. The select only chagnes the default, which can be overrided >> by the user via the menu. This allows kconfig fragments to work >> for make defconfig, while not restricting user customization. >> >> Thoughts and feedback (or alternate approaches) would be appreciated. >> >> thanks >> -john >> >> CC: Grant Likely <grant.likely@secretlab.ca> >> CC: Jason Hui <jason.hui@linaro.org> >> CC: patches@linaro.org >> Signed-off-by: John Stultz <john.stultz@linaro.org> > > The patch looks fine to me (as far as my little Kconfig > knowledge goes). Two comments about the submission form though: > > * Ideally, the initial description is split into two parts: one > that is suitable as a changelog and the other that is your > personal comment, including the "thanks" part, and put it below > the --- line, so that git can automatically cut it. > > * I think you should also Cc the Kconfig maintainer, Roman > Zippel <zippel@linux-m68k.org>, and linux-kbuild@vger.kernel.org. And linux-kernel. This definitely needs wider circulation, and I'd like to see a push to get this accepted upstream before adding it to the Linaro kernel tree. g.
On Wed, 2011-03-09 at 09:38 +0100, Arnd Bergmann wrote: > On Wednesday 09 March 2011 03:32:35 John Stultz wrote: > > Thoughts and feedback (or alternate approaches) would be appreciated. > > > > thanks > > -john > > > > CC: Grant Likely <grant.likely@secretlab.ca> > > CC: Jason Hui <jason.hui@linaro.org> > > CC: patches@linaro.org > > Signed-off-by: John Stultz <john.stultz@linaro.org> > > The patch looks fine to me (as far as my little Kconfig > knowledge goes). Two comments about the submission form though: > > * Ideally, the initial description is split into two parts: one > that is suitable as a changelog and the other that is your > personal comment, including the "thanks" part, and put it below > the --- line, so that git can automatically cut it. Yea, although early on I tend to be a little more informal, I do usually clean up the commit log before actually submitting anything more then RFC level code. > * I think you should also Cc the Kconfig maintainer, Roman > Zippel <zippel@linux-m68k.org>, and linux-kbuild@vger.kernel.org. This patch was actually submitted to both a few weeks ago. In this case, as I'm trying to RFC the overview of what I'm trying to accomplish specifically on the linaro list, I trimmed the cc list. Once I sort out the Linaro distro policy bits, and can drop the last quarter of the patch set, I'll likely resubmit the entirety to the kbuild list (and Roman, although he seems to be MIA these days). thanks for the feedback! -john
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c index af6e9f3..c4f3e49 100644 --- a/scripts/kconfig/symbol.c +++ b/scripts/kconfig/symbol.c @@ -203,8 +203,6 @@ static void sym_calc_visibility(struct symbol *sym) sym->visible = tri; sym_set_changed(sym); } - if (sym_is_choice_value(sym)) - return; /* defaulting to "yes" if no explicit "depends on" are given */ tri = yes; if (sym->dir_dep.expr) @@ -235,9 +233,22 @@ static void sym_calc_visibility(struct symbol *sym) struct symbol *sym_choice_default(struct symbol *sym) { struct symbol *def_sym; + struct symbol *ret = NULL; struct property *prop; struct expr *e; + /* check to see if any are selected */ + prop = sym_get_choice_prop(sym); + expr_list_for_each_sym(prop->expr, e, def_sym) + if (def_sym->rev_dep.tri != no) { + if (ret) + printf("Error! Conflicting selects! %s\n", def_sym->name); + else + ret = def_sym; + } + if (ret) + return ret; + /* any of the defaults visible? */ for_all_defaults(sym, prop) { prop->visible.tri = expr_calc_value(prop->visible.expr);
In looking at trying to replace defconfigs with kconfig fragments, one limitation identified is that config items in choice blocks cannot be selected by other config options. One way to doge this would be to create non-visible meta options that change the choice block's default, but that would require additional meta-configs per-choice config, plus a conditional default per meta-config. That just seemed too ugly. So I looked into how to allow the choice default to be overrided by a select statment, and the following patch is the result. I'm very new to kconfig code, so I expect that my changes are probably broken in some subtle way, but in my testing it seems to work. The select only chagnes the default, which can be overrided by the user via the menu. This allows kconfig fragments to work for make defconfig, while not restricting user customization. Thoughts and feedback (or alternate approaches) would be appreciated. thanks -john CC: Grant Likely <grant.likely@secretlab.ca> CC: Jason Hui <jason.hui@linaro.org> CC: patches@linaro.org Signed-off-by: John Stultz <john.stultz@linaro.org> --- scripts/kconfig/symbol.c | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-)