lkml.org 
[lkml]   [2008]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 06/16] Markers auto enable tracepoints (new API : trace_mark_tp())

* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> 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


\
 
 \ /
  Last update: 2008-11-23 17:53    [W:0.058 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site