Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

[Karim Yaghmour <karim@opersys.com>]

Ingo Molnar wrote:
> There's a third option, and that's the one i'm advocating: adding the 
> tracepoint rules to the kernel, but in a _detached_ form from the actual 
> source code.
> 
> yes, someone has to maintain it, but that will be a detached effort, on 
> a low-frequency as-needed basis. It doesnt slow down or hinder 
> high-frequency fast prototyping work, it does not impact the source code 
> visually, and it does not make reading the code harder. Furthermore, 
> while a single broken LTT tracepoint prevents the kernel from building 
> at all, a single broken dynamic rule just wont be inserted into the 
> kernel. All the other rules are still very much intact.

Actually the way ltt used to add its trace-statements is again an
implementation issue. Broken tracepoints need not lead to kernel
build failure.

That's where the markers idea can be useful. What a marker should
do is but provide location. It doesn't need to specify the variables
being observed or anything local, though it doesn't mean the
infrastructure shouldn't allow for this if the maintainer of the
code wanted to.

Ideally, though, markers should be self-contained. IOW, the person
implementing such a marker should not need to edit any other file
that the one being worked on to add an instrumentation point --
at least that's the way I think is easiest. What this means is that
you would be able to add an instrumentation point in the kernel,
build it, run the tracing and view the trace with your new event
without any further intervention on any tool, header, or anything
else.

The only way that I believe this can be done is with a flexible
marker infrastructure that a has a few basic properties:
- Markers should be inlined (clearly this is the bone of contention
  at this point of the thread.)
- By default, all markers should generate not a single instruction
  or modify any instruction path that would be generated should the
  the instrumentation not be there.
- Allow the person instrumenting to specify which variables they
  are interested in without any possibility of build failure should
  the code change making the variable obsolete.
- Build options should be added allowing users to:
  - Keep instrumentation disabled.
  - Create inlined trace points.
  - Create dynamic instrumentation markers.
  - Automatically generate appropriate information required for
    tools to be able to deal with the new instrumentation and/or
    display new information properly -- possibly in a new section
    of the binary.
  - etc.

Again, the goal is to have the loop from instrumentation to
visualization as simple as possible. Any instrumentation required
more that single-file modification is bound to fall in bitrot,
and fast.

Hope this helps.

Thanks,

Karim