The symbol 'mcount' has EXPORT_SYMBOL_GPL attached to it. This is because "things that use this symbol are too chummy with kernel internals to not be derivative". However, the symbol may or may not actually be referenced by a given module, depending on the setting of CONFIG_FTRACE. This leads to an interesting result: The module may or may not be too chummy depending on a variable outside its control, and the module source code doesn't have any say in the matter. So we have a .c file that *is* a derivative work if the kernel is built one way, and is *not* if the kernel is built another. Worse yet, it *also* depends at runtime on the setting of /proc/sys/kernel/ftrace_enabled
But it's the SAME EXACT SOURCE. And since the source file isn't called schrodinger.c, I believe the following patch is in order.. (As an aside, arch/um/kernel/gprof_syms.c already lists mcount as a SYMBOL, not a SYMBOL_GPL - yet another inconsistency. Signed-off-by: Valdis Kletnieks <[EMAIL PROTECTED]> --- --- linux-2.6.25-rc2-mm1/kernel/trace/ftrace.c.dist 2008-02-16 23:34:36.000000000 -0500 +++ linux-2.6.25-rc2-mm1/kernel/trace/ftrace.c 2008-02-25 12:00:57.000000000 -0500 @@ -44,7 +44,7 @@ static struct ftrace_ops *ftrace_list __ ftrace_func_t ftrace_trace_function __read_mostly = ftrace_stub; /* mcount is defined per arch in assembly */ -EXPORT_SYMBOL_GPL(mcount); +EXPORT_SYMBOL(mcount); notrace void ftrace_list_func(unsigned long ip, unsigned long parent_ip) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/