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

[Jes Sorensen <jes@sgi.com>]

Karim Yaghmour wrote:
> Jes Sorensen wrote:
> There is in my view, and this is what this whole debate is really
> about, a clear difference in between the type of instrumentation
> being added. Clearly in the view of others there just isn't. But
> bare with me. I submit to you that there are 3 classes of trace
> points:
> 
> - OS-class: These are trace points which will be found in a given
>   kernel regardless of how it is implemented if it belongs to a
>   certain family of OSes. Linux being made to mimic Unix, it will
>   always have key events. And if you look closely at the initial
>   set of points added by ltt, these would be found in any Unix.
>   It's not for nothing that my paper on ltt was accepted at Usenix
>   2000 - and in fact during the question period somebody asked how
>   easy it would be to port it to BSD, and the answer: trivial.

There very few tracepoints in this category, the only things you can
claim are more or less generic are syscalls, and tracing syscall
handling is tricky.

> - Subsystem-class: These are trace points which are specific to
>   a given implementation. Say block tracing, scsi tracing, etc. as
>   they are implemented in Linux. The purpose of these is to allow
>   a user of these given subsystems to get more in-depth understanding
>   of what's happening inside the box.

This is grossly over simplifying things and why the whole things doesn't
hold water. There is no such thing as 'the place' to put a specific
tracepoint.

Especially when we start talking about things like tracepoints in the
scheduler.

Note that I haven't been referring to debug tracepoints at any point in
this debate.

>> It will be a drag because next week someone else wants a tracepoint
>> 5 lines further down the code! Again, I have seen people try and do
>> that on top of the old LTT patchsets, so maybe *you* didn't want the
>> tracepoint somewhere else, but some people did! Next?
> 
> Not if you understand the distinction I am making above.

Your distinction above doesn't hold water, but I did understand it
very well ....

You seem to think that it's fine to add instrumentation in the syscall
path as an example as long as it's compiled out. Well on some
architectures, the syscall path is very sensitive to alignment and there
may be restrictions on how large the stub of code is allowed to be, like
a few hundred bytes. Just because things work one way on x86, doesn't
mean they work like that everywhere.

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