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


Paul Mundt wrote:
Which brings back the point of static tracepoints being entirely
subjective. By this line of reasoning, you define for other people what
the useful tracepoints are, and couldn't care less which points they're
actually interested in. How exactly is this serving the need of people
looking for instrumentation, rather than a pre-canned view of what they
can trace? If they already have to go with their own tracepoints for the
things they're interested in, then having a few static points
pre-existing doesn't really buy anyone much else either, especially if
by your own admission you're not integrating the points that people
_are_ interested in.

I'm not indicating that you didn't do exactly what you should have in
this situation, only that static tracepoints in general are only going
to be a small part of the picture, and not a complete solution to most
people on their own. Dynamic instrumentation fills the same sort of gap
without worrying about arbitrary maintenance, so what exactly does
shoving static instrumentation in to the kernel buy us?

And this flies in the face of all of those who, for years, have been
satisfied customers for ltt and who were more than looking forwad
for not having to depend on me to get a working traceable kernel.

The static tracepoints we maintained were *the* solution for a great
deal many people. As a maintainer I had two choices with those who
were not content:
a- Maintain their tracepoints for them -- not happening.
b- Suggest they contribute to helping getting a generic tracing
infrastructure into the kernel and then make their case on the
lkml as to the pertinence of their instrumentation.

And what I did is "b". I wasn't going to defend anybody else's
choice of tracepoints. Those who were using ltt for its designated
purpose -- allowing normal users and developers to get an accurate
view of the behavior of their system -- were very happy with it.

You want to know who was unhappy with using it: kernel developers.
It just wasn't geared for them. Which goes back to my earlier
arguments ...

Karim

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

Relevant Pages

  • Re: 2.6.11-rc1-mm1
    ... > data, etc., and 2) a static list of generally useful tracepoints. ... I have no objection at all to put instrumentation into the kernel. ... Merge the instrumentation points from ltt and other projects like DSKI ... the burden into postprocessing and provides a simple postmortem dump ...
    (Linux-Kernel)
  • Re: [patch 4/4] KVM-trace port to tracepoints
    ... Tracepoints allow dormat instrumentation, like the kernel markers, but also ... This patch depends on the "Tracepoints" patch. ... Is it a specific property of KVM-trace that causes this LOC blow-up? ... strings into the kernel code, which, to some, looks like debugging code. ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... kernel infrastructure. ... Tracepoints of course need to be managed, ... and thus is zero maintainance overhead. ... i frequently break my kernel via static tracepoints and i ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... engineers trying to debug things on a live, production system) want to ... Static tracepoints on the other hand, if added via an external patch, do ... Instrumentation of function boundaries is usually not much of an issue. ...
    (Linux-Kernel)
  • Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
    ... If they already have to go with their own tracepoints for the ... the various small add-hoc tracing facilities. ... Dynamic instrumentation fills the same sort of gap ... shoving static instrumentation in to the kernel buy us? ...
    (Linux-Kernel)