Re: tracepoint maintainance models

[Karim Yaghmour <karim@opersys.com>]

Ingo Molnar wrote:
> are you saying that if i replaced half of the static markups with 
> function attributes (which would still provide equivalent functionality 
> to dynamic tracers), or if i removed a few dozen static markups with 
> dynamic scripts (which change too would be transparent to users of 
> dynamic tracers), that in this case users of static tracers would /not/ 
> claim that tracing broke?

Is this is a 3-for-1 combo? Here's an answer to each:

1- static markup replaced by function attributes:

Verbatim answer from earlier email
> What is sufficient for tracing a given set of events by means
> of binary editing *that-does-not-require-out-of-tree-maintenance*
> can be made to be sufficient for the tracing of events using
  ^^^^^^^^^^^^^^
> direct inlined static calls.

But since you insist on nitpicking ... nothing precludes earlier
mentioned build-time script from being instructed to act in a
similar fashion with regards to generating alternate build files
as described earlier but with using function attributes as the
cue instead of static markup.

2- removed markups are not transparent to "static" tracers:

False. LTTng couldn't care less. Though you'd have a point if
we talked about the *old* ltt, but we aren't.

3- users of tracing will *only* complain if they're using
"static" tracers:

False. You've quite elegantly stated that users don't give a damn
about *mechanism*. So the potential for complaint is, therefore,
no different. More practically: LTTng/SystemTap/LKET is aimed at
the same crowd. There's no factual basis to support the claim
that users of LKET or SystemTap are less likely to complain about
broken tracing that users of LTTng. In fact, there is ample
factual evidence to the contrary. And, *again*, LTTng will not
*break* because of missing events simply because it's a
framework for the analysis of large event sets, which the *old*
ltt never was.

> i fully understand that you can _teach_ the removal of static 
> tracepoints to LTT (and i'd expect no less from a tracer), but will 
> users accept the regression? I claim that they wont, and that's the 
> important issue.

You can claim to be Santa Claus if it makes you happy, but the
factual record does not support the claim that LKET or SystemTap
users are less likely to complain than LTTng users. Again, the
factual record actual supports quite the opposite. And yet *again*,
LTTng is a framework for the analysis of large event sets. It
does *not* need to be *taught* about the removal of anything,
it presents what information it does have. Any fixing of
existing analysis plugins that depend on given event sets, _if
at all required_, is no different from the requirement to fix
scripts which analyze a fixed set of events collected by
SystemTap. LTTng is, in fact, less susceptible to breakage
than LKET, which does depend on a given set of events, even
if it's using a "dynamic" trace mechanism.

> Frankly, i find it highly amusing that such seemingly 
> simple points have to be argued for such a long time. Is this really 
> necessary?

I'm afraid it is. And the reason I think it's necessary is that
you've been advertising yourself as an expert about everything
tracing, and *that* is: a) just untrue (and therefore misleading),
b) absolutely insulting to all those -- and forget me from the
picture -- who invested *considerable* resources into developing
any form of tracing for Linux, especially considering the
*extremely* tight framework given to them by kernel developers. If
you would care to ask *and* listen, Ingo, those people who you so
blatantly choose to ignore would be more than happy to present
their work and ideas to you. Just try it: ask *and* listen.

Karim
-- 
President  / Opersys Inc.
Embedded Linux Training and Expertise
www.opersys.com  /  1.866.677.4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/