student for gsoc2008

[Joel Sherrill]

Reng Zeng wrote:
> Hi Joel, Chris and all,
>
> Other than this project, I also have some ideas as below, just what I 
> could think of while trying to understand this project, it may be 
> wrong or inappropriate for RTEMS,  anyway, your any comments would be 
> highly appreciated.
Attached is an example of using the GNU ld --wrap argument to wrap all
calls to malloc. 

I wrote a program which could be provided a list of function prototypes and
produce wrapper functions similar to the one shown in the attached code.
But it would put all the arguments along with a event type indicator in 
a buffer
and pass that all to the capture engine.

Chris was sure he could take the same list of function prototypes and auto
generate python code to decode the trace log.
>
> 1.  For the log generated from run-time trace, the capture engine code 
> only has Thread_Control as input, if we had another parameter there, 
> that could make it possible for RTEMS application to add customized 
> info into the log. For example, if the run-time trace is used to trace 
> the phone call usage, it may be required to have user id info included 
> into the log.
>
Agreed.  Chris and I discussed passing a buffer along with the event type. 
> 2. I guess, the run-time trace is mainly for debug purpose since it 
> impact the performance anyway, especially in case high traffic. Is 
> there any measurement available for specific characteristic? For 
> example, user may be interested to know average CPU utilization in the 
> past 5 minutes, 30 minutes, and 24 hours.
Exactly.  It would indeed add overhead -- both CPU and precious 
communications
bandwidth.  The user would have to have the capability to filter the 
events logged.
I recall Chris and I identifying two points:

+ methods actually wrapped.  If it isn't wrapped, this this executable 
won't be
able to trace that method.
+ A boolean expression filter in the capture engine to let logging 
happen but say that
 you only want events from a particular task.

RTEMS keeps cpu utilization statistics but there would be nothing wrong 
with snapshotting
this and having a log message for it.  But remember, you could derive 
this information
from the constext switch traces in the logging information.

All RTEMS systems do not have filesystems.  Most will not have any type 
of permanent
storage at all to write data into.  They will have to use some type of 
communications
mechanism like TCP/IP to get the data off board dynamically.  The 
communication
mechanism may be unusual like CanBUS or something else.  This is a deeply
embedded system. :-D

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrap.tar.bz2
Type: application/x-bzip
Size: 741 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20080321/25477cc5/attachment-0001.bin>