[ltt-dev] tracepoint layer and marker layer

[Mathieu Desnoyers]

* Jan Blunck (jblunck at suse.de) wrote:
> On Thu, Sep 18, Mathieu Desnoyers wrote:
> 
> > No. Tracepoints are by no mean a replacement for the markers.
> > Tracepoints do not include the format string that is exported by markers
> > to userspace to keep track of event typing.
> 
> So you are talking about the LTTng kernel->userspace API. What happens when
> the API is changing? Is the userspace application capable of parsing the
> format string exported by the markers to handle the change? If not, for what
> purpose is it used than?
> 

Yes, the userspace app is expected to read the strings and follow the
changes. But say an application expects some information to perform
specific analysis. Changing this information should not be done directly
in the C core kernel code. I should be more visible, and thus in a
global header.

So we should expect the userspace app to support content modification,
but that it may expect some core content to perform basic analysis, like
keeping track of the current running thread on each CPU. This would
therefore be a tracepoint.

> > A patch implementing what I proposed below will be available ASAP.
> 
> Thanks, that's great.
> 

It's now in lttng 0.21, pushed on ltt.polymtl.ca and kernel.org in
tarballs and git trees.

See mainly markers-auto-enable-tracepoints.patch

Note that I had to use my preemptable rwlock implementation to cleanup
the hell that taking the module_mutex would have been to read the module
list in a nested markers, tracepoints and immediate values. The sane way
to do this is to have a preemptable reader side of a "reader-writer
mutex", which can actually be done by psrwlock. This is why I include it
in this patchset.

I also refactored the patchset to bring the LTTng patches at the
beginning, given that it's now more important to focus on the data relay
mechanism than the instrumentation.

Regards,

Mathieu

> Regards,
> 	Jan
> 
> -- 
> Jan Blunck <jblunck at suse.de>
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68