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

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

Hi,

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Frank Ch. Eigler <fche@redhat.com> wrote:
> 
> > As for Karim's proposed comment-based markers, I don't have a strong 
> > opinion, not being one whose kernel-side code would be marked up one 
> > way or the other. [...]
> 
> What makes the difference isnt just the format of markup (although i 
> fully agree that the least visually intrusive markup format should be 
> used for static markers, and the range of possibilities includes 
> comment-based markers too), but what makes the differen is:
> 
>  the /guarantee/ of a full (comprehensive) set to /static tracers/
> 
> The moment we allow a static tracer into the upstream kernel, we make 
> that guarantee, implicitly and explicitly. (I've expanded on this line 
> of argument in the previous few mails, extensively.)
> 

Ingo, your definition of a static tracer seems to be slightly off from LTTng's
reality in two ways :

First, the kernel tracer supports dynamically loadable "event types", which
makes it quite more flexible than a static tracer that would have to guarantee
a full set of trace points. There is a clear difference between statically
adding instrumentation and statically adding new event types in that forcing a
static set of events would indeed break the user space tools when an event is
added or removed.

Second, the user space analysis tools are built so that they can handle missing
information. So, if they lack things like scheduler change or irq entry/exit
events, they will still show the available information. No "breakage" would
result from a missing probe. Moreover, the LTTV trace analysis tool being
modular and plugin-based, developers can choose to load or not analysis on the
data based on the instrumentation present in the traced kernel.

So there is no guarantee of any full instrumentation set : both instrumentation
and analysis tools are extensible by the users when needed.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68