Timeline Tool

[Thomas Doerfler]

Manuel,

Manuel Coutinho schrieb:
> 
> The Manager approach has a good advantage: the user can enable/disable
> (almost completely remove the tool from the memory footprint) the timeline
> tool in the application Makefile. The low memory overhead is quite important
> for space users since space limitation is an issue. With the Manager
> approach the user doesn't have to build the RTEMS library twice (one with
> the tool and another without the tool). Furthermore, this integration
> follows the standard approach on the RTEMS Classic API.

Hm, this is something I do not understand. You insist on the
requirement, that the application must not be modified to enable/disable
the Timeline Tool (which I understand), but modifying the Makefile is
allowed? Strictly speaking many settings in the Makefile are also
important to generate a specific binary. The difference between
modifying the Makefile and modifying "system.h" seems rather small to me.

> 
> The tool will monitor more events, so the tool needs to be extended. Even
> though the tool is required not to change the application, for "non-space"
> users we are planning to create an API that allows, like the capture engine,
> to dynamically reconfigure the filter parameters. We are thinking of getting
> some ideas to do this from the capture engine.
> 

It would be nice to have a monitor tool as an option, not a requirement.
If the timeline data structures are formed properly, it should be
possible to have an optional simple frontend for user interaction.
Although this may not be available in the beginning, it would be nice to
at least have the possibility (speaking: a proper internal interface) to
set the filters and/or display part of the traced data.

> 
> The tool must be able to trace interrupt generation. A filter will be placed
> to choose what sources to trace. We are thinking of using the
> rtems_interrupt_catch routine to save the old ISR handler and replace it
> with our own. Our ISR handler saves the interrupt event and calls the old
> handler. We must take special care not to place our handler until the
> application places its own (must be done after the drivers are initialized).
> 

Please keep in mind, that unfortunately the interrupt API is in transit.
rtems_interrupt_catch is fine for SPARC, m68k and friends, bit we have a
different approach in PowerPC/i386. It would be nice f tapping the
interrupts would also work there, meaning that this API is also
integratable. :-) Please let me know if we can help there :-)

> 
> The application is everything outside RTEMS. The space users (and possibly
> other) can have a certified application, which cannot be changed, which they
> want to further analyze with the timeline tool.
> If we change the confdefs file to create a new starting task the problem
> remains because the application needs to be recompiled. 

I think the distinction, what is "application" and what is "OS/Services"
is quite difficult. Strictly speaking you also must recompile the
application if you modify the Makefile.

I agree with Chris, that recompiling RTEMS every time I want to
enable/disable the Timeline Tool is not a good solution. In former
times, we had two versions of the RTEMS "library", one with and another
one without debug support. I think for most architactures, this is no
linger true. But how about that:

- When RTEMS is configured, there could be an option to generate an
additional library version, which includes Timeline Support into the
various RTEMS sections (instrumentation) and also includes the transport
layer etc.

Then it is the user's option, whether the application links against the
instrumented version of RTEMS or against the one without instrumentation.

Manuel, just another (small?) requirement: for many applications, it
would be nice to trace application specific events, like "task xxx has
received all its configuraton data and now can start working" or "task A
starts/terminates processing data". So it would be nice to have the
ability to set user-named/private tracepoints. Is this possible?

wkr,
Thomas.


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.