Mathieu Desnoyers wrote:
* Andrew Morton ([email protected]) wrote:
> Of course, it they are properly designed, the one set of tracepoints could
> be used by different tracing backends - that allows us to separate the
> concepts of "tracepoints" and "tracing backends".
If I try to develop your idea a little further, we could this of dividing the
tracing problem into four layers :
- tracepoints (where the code is instrumented)
- identifying code
- accessing data surrounding the code
- tracing backend (how to add the tracepoints)
- tracing infrastructure (what code will serialize the information)
- data extraction (getting the data out to disk, network, ...)
I think you missing user-space post processing which should be also
considered part of the problem since the capabilities of post-processing
will be limited by the "tracepoints" available. Tracepoints and
post-processing are also the problems which need to be address first
between the other established tracing projects before going forward with
in-kernel solutions.
I think that, if we agree on this segmentation of the problem, this thread is
generally debating on the tracing backends and their respective limitations.
I just want to point out that the patch I have submitted adresses mainly the
"tracing infrastructure" and "data extraction" topics.
This seem like a good idea to dissect the problem since it seem like
other important issues relevant to general tracing are being ignore
simply because of a dislike of the way LTTng has chosen to implement trace.
-JRS
-
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]
