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

[Karim Yaghmour]

Ingo Molnar wrote:
> i actually think djprobes are pretty darn inventive.

So do I. While there is a language barrier, the Hitachi folks,
especially Hiramatsu-san, are very talented.

> I also think that 
> the tracebuffer management portion of LTT is better than the hacks in 
> SystemTap, and that LTT's visualization tools are better (for example 
> they do exist :-) - so clearly there's synergy possible.

Great, because I believe all those involved would like to see this
happen. I personally am convinced that none of those involved want
to continue wasting their time in parallel.

> But i have no 
> faith at all, for the many reasons outlined before, in the concept of 
> static tracing, because i see no possible future path out of its many 
> limitations and because i see no possible future way to get rid of their 
> dependencies.

Yes, I do so believe that this is what you most sincerely think. And
I'm ok with that. We don't have to approach the problem from the
same direction. In my view we should at least settle for working on
the most basic thing we *do* agree on: having a markup mechanism for
necessary instrumentation.

> So i'd rather wait some time for dynamic tracers to 
> outgrow static tracers in even the last final area, than let static 
> tracing into the kernel - which would add dependencies that we'd have to 
> live with almost until eternity.

I genuinely understand your concern. And I repeat that ltt's initial
design cared little of the provenance of the events. It just needed
key events to present an intelligent picture to the user. The
patches have since grown to include stuff which was essential as
development went ahead. But there's no reason things cannot be
refactored into an acceptable format to all by review on the lkml.

> it would clearly reduce the number of places where static markup would 
> still be necessary. With static tracers i see no such mechanism that 
> gradually moves the markups out of the kernel.

Again, I strongly believe that this issue isn't about static vs.
dynamic. The goal, and that's what's important, is to allow users
to have access to a set of tools they can use on *any* kernel
they get their hands on, without having to edit anything anywhere
or fix any script. For having spent considerable effort into this,
I don't see any other way that using static markup. Here's a
simple case: you ask someone who's got a bug report on a kernel
crashing because of his user-space realtime task, and you ask him
to dump you a trace, and that trace actually ends up misleading
because his out-of-tree instrumentation was inserted in the wrong
location.

Again, the goal is to obtain tools that users can use on *any*
kernel they get their hands on.

> So you dispute that markups for dynamic tracing will be more flexible 
> and you dispute that they will be less intrusive than markups for static 
> tracing?

No, I'm saying that the flexibility of the markup is not tied to the
instrumentation "grab" mechanism (direct call or binary editing.)
That's the "arbitrary" I'm talking about.

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/