Re: [PATCH] tracing: Export key trace event symbols

[Ron Rechenmacher]

Thanks for looking at the code and providing the feedback.

Using EXPORT_SYMBOL was a mistake. I just changed them to EXPORT_SYMBOL_GPL.
I've been doing this sort of "tracing" (which I consider the "minimum level of
complexity" tracing) for about 30 years. I've never made any money on this, nor do
I care to. For the last 25 years, I've worked at a US Dept. of Energy research facility
and consider all the stuff I do to be in the public domain. I, in no way, want to suggest
or even care if other want to use it or not. I won't even suggest that you might need it.
It has allowed me to do great work/research and I will patch the kernel manually it need be.
But if there is anything else I should do to the code to make is more public, please let me
know.

Exactly why I _need_ these symbols exported?:

When data acquistion systems I develop or am involved with at Fermilab, have near-realtime
performance issues, _my_ tracing system is what _I_ use. There is a user-space component to
it that can be used with or without the kernel module. Using the module allows me to
see interactions with the Linux OS.

Sure, there are other tools -- none which provide me "the minimum level of complexity"
( About once a year I take a week or 2 and learn the latest of what's available. )

There has been times in the past, when I've had a major experiment collaboration
load a patched kernel, but there is a certain level of inconvenience associated with that.


Currently, the major experiments are using a derivative of Redhat EL6 and there is not
a problem with creating and loading my module. I'm optimistic that there will not
be a problem with EL7 which has a base kernel derived form Linux-3.10.

I am, however, doing research on high speed networking and we are using the Linux-3.16.1
kernel, which I am currently patching.  In the future, it would be nice not to have to
patch the kernel.

The kernel currently exports:
     EXPORT_TRACEPOINT_SYMBOL_GPL(power_start)
and  EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle)

I understand that "Only the user space ABI is what we keep stable" and that before
commit de7b2973903c (tracepoint: Use struct pointer instead of name hash for reg/unreg
tracepoints) it was just "lucky" that I could have my module work.
But, I can image how these (the above EXPORTs) would be very useful for external
modules to help with custom power management. And, I suspect that if they went away,
someone would complain.

I would like to have my proposed patch included to provide similar
usefulness for my custom tracing (for the sake of science).

Please accept my patch.

Thanks for you consideration and if there is specific help/suggestion you can offer to
get my patch accepted, please let me know.

Thanks again for the discussion.

--Ron


Steven Rostedt wrote on 04/21/15 08:53:
> On Tue, 21 Apr 2015 08:26:26 -0500
> Ron Rechenmacher <ron@xxxxxxxx> wrote:
>
> > But why export anything _GPL in the first place?
>
> To make it clear that they are derivatives of the kernel. An export is
> just to allow modules access to the functions, they were not added for
> out of tree modules. Out of tree modules just happen to be lucky to
> have them available.
>
> Note, if you can present a good case to why they should be exported,
> then we should have no problem exporting them. But I just looked at
> your code, and I have some questions about it.
>
> EXPORT_SYMBOL( traceControl_p );
> EXPORT_SYMBOL( traceEntries_p );
> EXPORT_SYMBOL( traceNamLvls_p );
> EXPORT_SYMBOL( trace_allow_printk );
>
> You have non GPL exported functions. Why? Is this used by non GPL code?
>
> MODULE_LICENSE("GPL"); /* Get rid of taint message by declaring code as GPL */
>
> That comment is very telling.
>
> Maybe I'm reading into things, but until we understand exactly why you
> need these symbols exported, we wont exported them. There's no kernel
> ABI that we must stick to. Only the user space ABI is what we keep
> stable.
>
> -- Steve

--
Ron Rechenmacher
Engineer
Fermi National Accelerator Laboratory
Batavia, IL  60510
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/