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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

Ar Gwe, 2006-09-15 am 07:46 -0700, ysgrifennodd Martin J. Bligh:
> Moreover, subsystem experts know what needs to be traced in order to
> give useful information, and the users may not. It's a damned sight
> easier for them to say "oh, please turn on tracing for VM events
> and send me the output" than custom-construct a set of probes for
> that user, and send them off. There's a barrier to entry that just
> won't happen there.

That has nothing to do with the static or dynamic probe question.
Scriptable dynamic probes do everything your static probes do and more.

> Hell, look at all the debug printks in the kernel for example, and
> the various small add-hoc tracing facilities. If all we do is unite
> those, it'll still be a step forwards.

Look how many there are, look how they spread, tracepoints will do the
same.

> Dynamic probes do NOT reduce maintenance, they increase it.

Thats a logical fallacy to begin with. A dynamic probe can probe
anything a static probe can. So a static probe can be implemented with a
dynamic probe.

In other words if you like static probe lists and your subsystem happens
to be one where it is useful then you can script it with the same effect
and send people the script.

With kprobes you've got a passably good chance (ie if Distros can be
persuaded to package the debug data) that you can say "run this
systemtap script". With static tracepoints its "recompile your vendor
kernel in your vendor manner with your vendor initrd and add it to the
boot loader"

Alan

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