Ingo Molnar wrote:
> also, the other disadvantages i listed very much count too. Static
> tracepoints are fundamentally limited because:
>
> - they can only be added at the source code level
Non-issue. See below. This is actually a feature, as can be seen
by browsing the source code of various subsystems/filesystems/etc.
who's authors saw fit to include their own static tracepoints.
Darn, they must've been all misguided, so too were those who
reviewed the code and let it in.
> - modifying them requires a reboot which is not practical in a
> production environment
Non-issue. See below.
> - there can only be a limited set of them, while many problems need
> finegrained tracepoints tailored to the problem at hand
Non-issue. See below.
> - conditional tracepoints are typically either nonexistent or very
> limited.
I don't get this one. What's a "conditional tracepoint" for you?
> for me these are all _independent_ grounds for rejection, as a generic
> kernel infrastructure.
I've addressed other issues in another posting, but I want to
reiterate something here that Roman said that keeps getting
forgotten:
There is no competition between static and dynamic trace points.
They are both useful and complementary. If some set of existing
static trace points are insufficient at runtime for you to
resolve an issue, nothing precludes you from using the dynamic
mechanisms for adding more localized instrumentation.
Side point: you may be a kernel god, but there are mere mortals
out there who use Linux. The point I've been making for years
now is that there are legitimate reasons why normal non-kernel-
developer users who would benefit greatly from being able to
have access to tools that generate digested information
regarding key kernel events. You can argue all you want about
maintainability, and I continue to think you're wrong, but
you should know that the development and usefulness of any such
tools is gated by the continued inability to have a standard
set of known-to-be-good source of key kernel events. And I
repeat, the use of dynamic tracing does *not* solve this
issue.
At OLS2005 I had suggested a development of a markers infrastructure
who's users could use just to mark-up their code, the decision
for tying such markers to a given type of instrumentation not
actually being tied to the markers themselves. At OLS this
year a very good talk was given on this topic by Frank from the
systemtap team and it was very well received by the jam-packed
audience. IOW, while there used to be a time when people pitted
static instrumentation against dynamic instrumentation, there's
been an ever growing consensus that no such choice need be made.
Thanks,
Karim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
