lkml.org 
[lkml]   [2009]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] tracing/markers: make markers select tracepoints
Frederic Weisbecker wrote:
> Sometimes it happens that KConfig dependencies are not handled
> like in the following scenario:
>
> - config A
> bool
>
> - config B
> bool
> depends on A
>
> -config C
> bool
> select B
>
> If one selects C, then it will select B without checking its dependency to A, if A
> hasn't been selected elsewhere, it will result in a build crash.

as documented in Documentation/kbuild/kconfig-language.txt (and yes, it is
considered to be a shortcoming/problem by most people AFAIK):

Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
kconfig should one day warn about such things.

> This is what happens on the following build error:
>
> kernel/built-in.o: In function `marker_update_probe_range':
> (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
> kernel/built-in.o: In function `marker_update_probe_range':
> (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
> kernel/built-in.o: In function `marker_update_probe_range':
> (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
> kernel/built-in.o: In function `marker_update_probes':
> marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'
>
> CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter depends on CONFIG_TRACEPOINTS
> which will not be selected.
>
> A temporary fix is to make CONFIG_MARKER select CONFIG_TRACEPOINTS, though it doesn't
> fix the source KConfig dependency handling problem.
>
> Reported-by: Ingo Molnar <mingo@elte.hu>
> Cc: Roman Zippel <zippel@linux-m68k.org>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
> init/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index b6400a5..a93f957 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -975,7 +975,7 @@ config TRACEPOINTS
>
> config MARKERS
> bool "Activate markers"
> - depends on TRACEPOINTS
> + select TRACEPOINTS
> help
> Place an empty function call at each marker site. Can be
> dynamically changed for a probe function.

but using "select" instead of "depends on" just causes the kind of problem
that you described, whereas using "depends on" does follow dependency
chains.

--
~Randy


\
 
 \ /
  Last update: 2009-02-20 18:01    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site