[Xenomai-core] RE: LTTng intergration roadmap

2006-05-17 Thread ROSSIER Daniel
Hi Jan,

Sorry for my late answer.

 -Message d'origine-
 De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Envoyé : lundi, 15. mai 2006 17:18
 À : xenomai-core
 Cc : Alexis Berlemont; ROSSIER Daniel
 Objet : LTTng intergration roadmap
 
 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?
 

Yes, it's right; my student is actually working on a first investigation in 
order to prepare its diploma project which starts from October to December.
So, the most insteresting results should not come up until then. 

The project consists in enhancing LTTng with Xenomai events and some specific 
algorithmic filtering on the related events, such as detecting abnormal 
situations (deadline misses, priority inversion at a certain level, etc.); the 
way how events are presented are also an issue to be considered (events per 
threads and not per process, different ways to represent the events). We are 
therefore very open to some proposals and ideas.
The interesting thing is that Jean-Olivier (the student) will perform his 
project at Matthieu Denoyers's premises at Montreal; besides, he already 
visited him to have first discussions. I think this will help us greatly.

 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.
 
 Jan

Thanks also to Alexis. The way how to generated lttng events matches with how 
we're doing now; we will also examine his Xenomai events and give you a 
feedback.

Of course, we keep the forum informed about the progress, but as mentioned 
before, it risks to evolve quite slowly on our side since the big project is 
for the three last months.

Daniel


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RE: LTTng intergration roadmap

2006-05-17 Thread Romain Lenglet
ROSSIER Daniel wrote:
 The project consists in enhancing LTTng with Xenomai events
 and some specific algorithmic filtering on the related events,
 such as detecting abnormal situations (deadline misses,
 priority inversion at a certain level, etc.); the way how
 events are presented are also an issue to be considered
 (events per threads and not per process, different ways to
 represent the events).

For visualization, I recommend you to take a look at Pajé:
http://www-id.imag.fr/Logiciels/paje/

It is free software (LGPL):
http://forge.objectweb.org/projects/paje/

I have seen it used for the visualization of events (for the 
analysis of deadlocks, etc.) in a heavily multi-threaded Java 
application. A custom Linux module collected all the events, and 
Pajé was used post-mortem for visualization of the events.
It seems very similar to what you want to do, except that you 
would use LTTng instead of a custom module to record events.

And there are nice publications about Pajé for your student to 
cite. ;-)

-- 
Romain LENGLET

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


[Xenomai-core] Re: LTTng intergration roadmap

2006-05-15 Thread Alexis Berlemont
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. 

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 ...

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 ?

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?

Jan, 

Yesterday I told you that that Matthieu Desnoyers proposed a new way of 
defining custom events since my last patch proposal. That was false: MD 
proposed his new method before my patch proposal; however, the genevent 
features kept on evolving. Sorry that was not very clear.

Best regards.

Alexis.


facility name=xenomai
  descriptionThe Xenomai facility has events related to Xenomai process 
execution./description  

  event name=xeno_timer_tick
descriptionXenomai timer tick/description
field name=runthreadstring//field
  /event

  event name=xeno_irq_enter
descriptionXenomai irq enter/description
field name=irquint size=4//field
  /event

  event name=xeno_irq_exit
descriptionXenomai irq exit/description
field name=irquint size=4//field
  /event

  event name=xeno_resched
descriptionXenomai reschedule event/description
  /event

  event name=xeno_smpsched
descriptionXenomai smp schedule event/description
  /event

  event name=xeno_fastsched
descriptionXenomai fast schedule event/description
  /event

  event name=xeno_switch
descriptionXenomai process switch/description
field name=fromstring//field
field name=tostring//field
  /event

  event name=xeno_fault
descriptionXenomai fault/description
field name=threadstring//field
field name=locationpointer//field
field name=trapuint size=4//field
  /event

  event name=xeno_callout
descriptionXenomai callout/description
field name=typestring//field
field name=threadstring//field
  /event

  event name=xeno_finalize
descriptionXenomai finalize/description