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

Roman Zippel
2006-09-16T20:00:26Z

Hi,

I don't know why you split this into multiple subthreads and instead of
delving further into secondary issues, please let me get back to the
primary issues to put everything a little into perspective.

The foremost issue is still that there is only limited kprobes support.
The way you ignore this and try to make this a non-issue makes it appear
to me rather arrogant, I appreciate it that you want to push technology
forward, but it's rather ignorant how you leave people behind in the dust
who can't keep up, by making it very hard for them to easily get access to
tracing in the kernel.
Since I have a quite good idea of the amount of work needed to implement
second rate kprobes hack, first rate kprobes support and first rate
ltt(ng) support, it's a quite simple decision what I'm going to do. Since
your "incentive" to add kprobes support is not very high, it's more likely
to backfire in making you the jerk denying me easy access to tracing
technologies.

Since my options are right now limited to a static tracer in first place,
most of the issues you mentioned over the various mails become really
moot, e.g. why should I care about the overhead of inactive traces? We can
happily discuss the merits of dynamic tracers forever, but it does _not_
change my current situation, that I have no access to one on some machines
I care about.

The main issue in supporting static tracers are the tracepoints and so far
I haven't seen any convincing proof that the maintainance overhead of
dynamic and static tracepoints has to be significantly different. What you
did is constructing a worst case scenario, which only proves that it's
possible, what it doesn't prove is that there are no measures to prevent
this from happining. This means nobody proved so far that it's not
possible to create and enforce a set of rules to keep the amount and
effect of tracepoints under control.
Let's take your example of a tracepoint in an area of high development
activity, since such development should happen in -mm, it would be no
problem to drop the trace and add it back once development calmed down,
exactly like you would do for a dynamic trace. OTOH it's very well
possible some people might find the trace useful during development.
So the problem here is now that you simply work from the unproven premiss,
that static tracepoints automatically lead to uncontrolled chaos. This
makes a reasonable discussion about managing tracepoints impossible, since
you don't want to support static tracepoints at all.

Ingo, as long as you don't give up this zero tolerance strategy, it
doesn't make much sense to discuss details and I can only hope there are
other people who are more reasonable...

bye, Roman