Re: tracepoint maintainance models

[Karim Yaghmour <karim@opersys.com>]

Ingo Molnar wrote:
> and now i'm red faced - i was wrong about this fundamental aspect of 
> your position. Please accept my apologies!

Apologies accepted. Hopefully we can tone this thread down and
move on to more constructive implementation discussions.

> so regarding the big picture we are largely on the same page in essence 
> i think - sub-issues non-withstanding :-) As long as LTT comes with a 
> facility that allows the painless moving of a static LTT markup to a 
> SystemTap script, that would come quite a bit closer to being acceptable 
> for upstream acceptance in my opinion.

I don't think there's any impediment for that. In fact, the value
is not in the markup, but in the tools.

> The curious bit is: why doesnt LTT integrate SystemTap yet?

Performance aside, this is due to historic reasons which cannot,
unfortunately, be succinctly explained. The best I can do is refer
you to the topmost parent of this thread, lengthy as it may be. As I
told Ted, if the signal *and* endorsement is that LTT and SystemTap
should be complementary, then that is exactly what will happen.

It doesn't solve the performance problem, but even the SystemTap
folks are concerned by performance and would like to see some form
of static markup, so I think the LTTng and SystemTap efforts are
on the same page here.

> Is it the 
> performance aspect? Some of the extensive hooking you do in LTT could be 
> aleviated to a great degree if you used dynamic probes. For example the 
> syscall entry hackery in LTT looks truly scary. I cannot understand that 
> someone who does tracing doesnt see the fundamental strength of 
> SystemTap - i think that in part must have lead to my mistake of 
> assuming that you opposed SystemTap.

I am not opposed to SystemTap and neither do I fail to see its
fundamental strength. It's just a matter that a decision was made
at some point in time that SystemTap be developed separately *and*
independently from any existing tracing effort. Again, that
decision was based on what appeared to be good reasons for the
people in charge, and there's no point in further highlighting
differences.

I think what is important at this stage is that now that we have
an agreement on the need for some form of static markup, that
the developers of the various teams work together to come up
with an acceptable framework for all to use. And, ideally, this
effort should be spearheaded by someone who has enough knowledge
of the kernel's intricacies as to avoid any obvious pitfalls.
In that regard, you're likely the best person to take charge of
this.

Once markup is in place, much of the mechanics of either of
the existing *mechanisms* can then simply disappear in the
background without *any* impact on the rest of the developers.

Only then will there start to be constructive discussion as
to where best markup should be located and what mechanism
is typically most appropriate for that specific location.

All that being said, I would like to thank you for acknowledging
a misunderstanding on your part. Hopefully we can all set this
aside, and move forward on common goals.

Thanks,

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/