[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130425134101.GA16609@gmail.com>
Date: Thu, 25 Apr 2013 15:41:01 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Michal Marek <mmarek@...e.cz>, LKML <linux-kernel@...r.kernel.org>,
Chris Metcalf <cmetcalf@...era.com>,
Christoph Lameter <cl@...ux.com>,
Geoff Levand <geoff@...radead.org>,
Gilad Ben Yossef <gilad@...yossef.com>,
Hakan Akkan <hakanakkan@...il.com>,
Kevin Hilman <khilman@...aro.org>,
Li Zhong <zhong@...ux.vnet.ibm.com>,
Oleg Nesterov <oleg@...hat.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Stephane Eranian <eranian@...gle.com>,
Jiri Olsa <jolsa@...hat.com>
Subject: Re: Kconfig doesn't support select on choices (was Re: [GIT PULL]
nohz: Adaptively stop the tick, finally)
* Frederic Weisbecker <fweisbec@...il.com> wrote:
> 2013/4/25 Ingo Molnar <mingo@...nel.org>:
> >
> > * Frederic Weisbecker <fweisbec@...il.com> wrote:
> >
> >> > depends on VIRT_CPU_ACCOUNTING_GEN
> >> >
> >> > It should _really_ select both the RCU and the CPU time accounting model
> >> > automatically!
> >>
> >> Yeah I know. I have yet to fix that in Kconfig (it's a Kconfig limitation).
> >
> > Why cannot we simply select it and its dependencies, explicitly, for the
> > time being? Something like:
> >
> > depends on 64BIT
> > select VIRT_CPU_ACCOUNTING
> > select VIRT_CPU_ACCOUNTING_GEN
> >
> > 90% of the .config's have VIRT_CPU_ACCOUNTING_GEN turned off, because it's
> > a default-off feature - so dynticks-full is effectively hidden from the
> > large majority of testers...
>
> Whatever we do, it seems that select does not work with choices.
>
> Michal, we are running into an issue where a Kconfig option needs to
> select CONFIG_VIRT_CPU_ACCOUNTING_GEN but this latter option is part of
> a choice menu so it doesn't work. As a result we are forced to use a
> "depends on" and this hides the high level option we are interested in
> (here full dynticks) behind its low level dependency. How hard do you
> think it would be to fix this? I tried something that worked half-way
> but I quickly got lost in the Kconfig maze.
While it's not an ideal solution, we could try to create three bools out
of the choice options, as a workaround?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists