Alexis Berlemont wrote:
> Hi,
> 
>> the need for a high-level tracing tool constantly increases with the
>> growing code base of Xenomai applications.
>>
>> Yesterday I started a short discussion with Alexis about the status of
>> his LTTng combo patch, the Xenomai integration, and the advances of
>> LTTng itself. But there are certainly more people interested in this
>> topic and may contribute ideas, comments, or even concrete code.
>>
>> Daniel, you once said that some of your students would start to work on
>> this topic. In which domain precisely, more at patch level or rather on
>> tools? What is the scheduled beginning and/or deadline for this thesis?
>>
>> Moreover, does anyone on this list recently tried LTTng on standard
>> Linux? Can we consider it reasonably stable and usable? One new thing
>> about LTTng internals which Alexis brought up were changes in the custom
>> tracing event interface. As this is a rather crucial point with respect
>> to the Xenomai instrumentation, we certainly do not want to change it
>> back and forth until LTTng stabilises.
> 
> Here is a little quotation from the LTTng Quickstart guide, I used it to 
> define the LTT events for Xenomai:
> 
> * Add new events to the kernel with genevent
> 
> su -
> cd /usr/local/share/LinuxTraceToolkitViewer/facilities
> cp process.xml yourfacility.xml
>   * edit yourfacility.xml to fit your needs.
> cd /tmp
> /usr/local/bin/genevent /usr/local/share/LinuxTraceToolkitViewer/facilities/yourfacility.xml
> cp ltt-facility-yourfacility.h ltt-facility-id-yourfacility.h \
>          /usr/src/linux-2.6.16-lttng-0.x.xx8/include/linux/ltt
> cp ltt-facility-loader-yourfacility.c ltt-facility-loader-yourfacility.h \
>          /usr/src/linux-2.6.16-lttng-0.x.xx/ltt
>   * edit the kernel file you want to instrument
>     - Add #include <linux/ltt/ltt-facility-yourfacility.h> at the beginning
>       of the file.
>     - Add a call to the tracing functions. See their names and parameters in
>       /usr/src/linux-2.6.16-lttng-0.x.xx/include/linux/ltt/ltt-facility-yourfacility.h
> 
> So, In order to test the combo patch adeos + LTTng I made:
> -> I wrote xenomai.xml (cf. attached file) which defines all the Xeno-LTT 
> events;
> -> I used genevent so as to generate the sources and the headers relative with 
> my events;
> -> Instead of copying them in the kernel, I integrated the sources in Xenomai. 
> I was considering that the Xeno events was independant from Linux. 
> 
> As a matter of fact, the last point should be rethought as the Xeno build 
> procedure is now integrated in the kernel. 

Not necessarily, you may still compile the nucleus as a module.

> 
> Things are simpler now, we could create an "I-pipe aware LTTng" patch which 
> could contain :
> -> the modifications in Relayfs (for a proper functioning with Adeos);
> -> the LTTng core stuff adapted for Adeos (not much work to do on this part);
> -> the Xenomai events in include/linux/ltt, and the loading code in ...

Hmm, I guess Philippe will not be happy to see Xeno-specific code in the
ipipe patch (like I had with my kgdb hack). Is there no clean way to
introduce this code together with the Xenomai installation, e.g. when
preparing the kernel with the script?

> 
> This patch would be applied after the I-pipe patch (in the same way as the 
> I-pipe tracer patch). So there would be no need to make combo patches, an 
> arch-independant additionnal patch would be easier to maintain.
> 
> What do you think of that ?

I do not overview every detail (I should actually look at the patch more
in detail, but - you know - time...). Everything that helps to reduce
maintenance costs while still keeping clean abstraction layers (ipipe is
 ipipe, xenomai is an independent add-on) is certainly good.

> 
> Eventually, concerning LTTng stabilisation status, I had a look a their 
> mailing-list (I am lurking on it since the beginning of LTTng) and at their 
> roadmap: starting from now, their TODO list contains integration and ports, 
> therefore undertaking an integration of LTTng with Xenomai (rigth now or next 
> month) does not seem too risky, does it?

Sounds good. Sounds at least like they found a stable design we can use
now - or soon when resources are available.

Jan