Re: [PATCH] tracing/markers: make markers select tracepoints

[Frank Ch. Eigler]

Hi -

> > The impression that this is somehow different with tracepoints 
> > is mistaken.  Tracepoints are *exactly* as "ABI-like" as 
> > markers.
> 
> they arent. To the kernel they look like function calls, with no 
> ABI properties at all. They can and will change without notice.

Markers also "look like" function calls because they are - the
callbacks just happen to take a format string and varargs.  What did
you think they were?


srostedt argues that separating the tracepoint from its rendering is
necessary to free the instrumentation site from backward-compatibility
stagnation.  

But consider - it has been manifold stated that tracepoints are not
welcome in the tree without a "tracer" (hand-written glue), so the
same person ends up writing both.  Since they are tightly coupled.  a
change on one will affect the other.  A moved tracepoint will produce
events at different times; a lost tracepoint parameter will lose data
at trace rendering time.  The tracing engine can only pretend to
produce the same data by guessing.

Similarly, if a marker site were to change, and if someone deemed the
old trace data important to preserve, a hand-written marker callback
function could replace a generic one, The new one could make the same
heuristic adaptation.

Try working out some examples.  You'll probably see how similar they
really turn out, with respect to the hypothetical "preserve ABI" idea.

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