student for gsoc2008

[Reng Zeng]

Thanks Joel's comments very much! See my input inline marked [Alan].

Regards,
Alan

2008/3/21, Joel Sherrill <joel.sherrill at oarcorp.com>:
>
> 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.


[Alan] What is the event type indicator here? Current capture engine provide
specific handler for each event. Now to integrate to capture engine from ALL
the wrapper function, it would have SOLE handler in capture engine, is that
right? Then besides all the arguments could be passed into capture engine,
what kind of event type indicator could be passed along here?

Chris was sure he could take the same list of function prototypes and auto
> generate python code to decode the trace log.


[Alan] For the "decode" here, do you mean the function name to be traced had
already been encoded to something?

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


[Alan]  Yes, the CPU utilization could be derived from context switch
traces. But how about memory utilization? And, how about if user is
interested to know what is the usage for specific semaphore?

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


[Alan] Understood. Thanks for the detailed explanation.

--
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080321/c0a786de/attachment-0001.html>