Timeline Tool

[Thomas Doerfler]

Hi,

now I also want to throw in my two cents...

First of all: I am happy something like the timeline tool gets written
and integrated into RTEMS, and I am also happy that (hopefully) the
timeline tool and the capture engine will form ONE tool, not two
distinct ways to do similar things.

But I have some comments to the recommendations from Manuel (and I
should have written them down earlier but... you know how it is...)



Manuel Coutinho schrieb:
> [Manuel] We can provide an interface that is device independent (i.e. writes
> to serial, Ethernet, flash disk, etc). If I understood you in your
> commentary above, the timeline tool is integrated as an RTEMS Manager so the
> user won't have to do --enable-rctt (or whatever) when building RTEMS. The
> user will only have to do something like
> 
> managers = io semaphore message timeline

WHen you deselct a manager in the applications makefile, its normal
functions are replaced by dummies, which normally throw an error when
called. For the timeline tool, it might make sense to add dummy
functions, that simple return to the caller. So the function call ist
still there, but the runtime impact will be reduced.

> 
> [Manuel] One of our requirements states that the timeline tool is
> "independent" from the application, that is, the tool can collect
> information even if the application does not call any timeline tool
> function. To do this the tool must be up and running prior to the
> application is started.

I think RTEMS supports multiple "init" tasks (specified in the
configuration in "system.h"), although most applications just have one
(called "Init"). This might be a place to add the timeline management
task prior to calling the first application task.
> 
> [Manuel] We are thinking of creation a file inside the RTEMS source code
> where the user can modify which calls are by default traced (not logged :)).
> The application can call a timeline tool API to, at runtime, enable/disable
> specific traces (e.g. want to monitor semaphore calls but not region nor
> partition). This file is a .c (or .h) file and by modifying these parameters
> the user would have to recompile RTEMS (at least this .c file).

I don't like the idea, that a different basic configuration requires
recompiling RTEMS. Wouldn't it be sufficent that the user, through some
magic mechanism, creates a data structure that defines, which (system)
calls are traced and which are ignored? The configuration mechanism for
this could be quite similar to the configuration mechanism available in
"system.h + confdefs.h".

In the past we had discussed to configure not only the kernel
parameters, but also other areas like file buffers etc. through an
extended, preprocessor based configuration mechanism. (The idea would be
to have a set of confdefs.h files at proper locations, which pull in
information from system.h, add defaults for items not specified by the
user and then generate a set of data structures).

> 
> [Manuel] Since (I think) we are moving in the direction of building a
> "Timeline Tool Manager", I think we don't need to create an extension to the
> RTEMS Extension Manager: the new functionality is implemented by the
> timeline tool Manager. This way, if the timeline tool manager is not
> selected, an empty function is called and no performance is lost (no "if" is
> performed). 

Please keep in mind: even calling an empty function has performance
impacts: The machine actually does not see, whether a called function
will be empty or not. So it will nevertheless save registers, possibly
write variables kept in registers back to memory etc before calling the
function.

I like the direction you are going!

wkr,
Thomas.
> 
>>
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users


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