Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls

On Wed, Feb 11, 2015 at 7:51 AM, Steven Rostedt [off-list ref] wrote:

On Tue, 10 Feb 2015 22:33:05 -0800
Alexei Starovoitov [off-list ref] wrote:

quoted

fair enough.
Something like TRACE_MARKER(arg1, arg2) that prints
it was hit without accessing the args would be enough.
Without any args it is indeed a 'fast kprobe' only.
Debug info would still be needed to access
function arguments.
On x64 function entry point and x64 abi make it easy
to access args, but i386 or kprobe in the middle
lose visibility when debug info is not available.
TRACE_MARKER (with few key args that function
is operating on) is enough to achieve roughly the same
as kprobe without debug info.

Actually, what about a TRACE_EVENT_DEBUG(), that has a few args and
possibly a full trace event layout.

The difference would be that the trace events do not show up unless you
have "trace_debug" on the command line. This should prevent
applications from depending on them.

I could even do the nasty dmesg output like I do with trace_printk()s,
that would definitely keep a production kernel from adding it by
default.

When trace_debug is not there, the trace points could still be accessed
but perhaps only via bpf, or act like a simple trace marker.

I think that is a great idea!
Makes it clear that all prints are for debugging and
no abi guarantees.

Note, if you need ids, I rather have them in another directory than
tracefs. Make a eventfs perhaps that holds these. I rather keep tracefs
simple.

indeed. makes sense. no reason to burn fs memory just
to get an id from name. may be perf_event api can be
extended to lookup id from name. I think perf will benefit as well.