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

[Steven Rostedt]

On Tue, 21 Apr 2015 10:00:25 -0500
Ron Rechenmacher <ron@xxxxxxxx> wrote:

> 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.

Heh, OK, I believe you :-)  it's just that we need to be careful about
this, as Christoph is even in the middle of litigation about GPL abuses.

> 
> 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.

I understand the _my_ tracing system. Before ftrace, I used logdev. Not
quite 30 years, but it started sometime in '98.

> 
> 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. )

If you have any suggestions to make the in kernel tracer better, please
feel free to make comments.

> 
> 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.

OK, lets see what you are doing in your patch:

+/*
+ * Allow modules to register additional trace routines
+ */
+EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_entry);
+EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_exit);
+

Instead of just saying "Allow modules to register additional trace
routines", please explain what its used for. What are you measuring
externally? Just the timings of the interrupts?

I'm also curious to know why ftrace isn't good enough.

Maybe the better solution is to add something to ftrace that does what
your tracer currently does?

-- Steve

> 
> 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.
--
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/