Re: [patch 06/16] Markers auto enable tracepoints (new API :trace_mark_tp())

[Ingo Molnar]

* Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx> wrote:

> > ... and in that sense i'd love to see lttng become a "super ftrace 
> > plugin", and be merged upstream ASAP.
> 
> Hrm, a big part of LTTng is its optimized buffering mechanism, which 
> has been more tested and is more flexible than the one currently 
> found in ftrace (it has supported lockless NMI-safe tracing for over 
> 2 years). It also separates the various tracing layers in separated 
> modules, which helps not mixing the buffer management layer with the 
> timestamping layer and with the memory backend layer.. I am opened 
> to try to merge ftrace and lttng together, but I think it will be 
> more than a simple "make lttng a ftrace plugin".

Sure, it will certainly be a fair bit of (interesting and useful!) 
work.

But it's something we should do iteratively, instead of merging a 
parallel framework. Steve's ring-buffer should be a fair step in the 
right direction. Could we improve on that?

i see nothing in the feature list of LTTng that we wouldnt want to 
have for ftrace, agreed? And we could do an ftrace tracer named 
'LTTng' which would interact with lttng userspace in the customary 
way.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/