Timeline Tool

[Manuel Coutinho]

> -----Original Message-----
> From: Thomas Doerfler [mailto:Thomas.Doerfler at embedded-brains.de]
> Sent: Friday, October 19, 2007 3:41 PM
> To: Manuel Coutinho
> Cc: 'Chris Johns'; rtems-users at rtems.org
> Subject: Re: Timeline Tool
> 
> 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] Agreed. The empty function shouldn't do anything. I didn't explain
this earlier...sorry...

> >
> > [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] You're right. I didn't remember this before. I was actually just
reading the confdefs.h file before I saw this email and I was wondering if
we could do this...looks like we can :). Some information that ran through
these emails can be somewhat misplaced because we initially were not
thinking of integrating the timeline tool as an "RTEMS Manager". This way, I
think the configuration of the timeline tool can be integrated into the
confdefs.h file (requires a task, an extension manager, etc).

> >
> > [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 sufficient 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".

[Manuel] We are expected to provide a default configuration which the user
can modify (and can possibly only modify this). Nevertheless, the timeline
tool will provide an API through which the application can modify at runtime
the configuration parameters. The RTEMS rebuild would only be necessary to
change the DEFAULT configuration.

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

[Manuel] You're right. I was just talking about the performance issue of the
"if" instruction. Nevertheless, I was wondering if there isn't a compilation
flag to optimize the access to empty functions...

> 
> I like the direction you are going!

[Manuel] Right on :)

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