student for gsoc2008

[Joel Sherrill]

Reng Zeng wrote:
> Thanks Joel's comments very much! See my input inline marked [Alan].
>
> Regards,
> Alan
>
> 2008/3/21, Joel Sherrill <joel.sherrill at oarcorp.com 
> <mailto: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
That is still TBD.  It could be a "class" indicator byte followed by an 
class specific
event.  Something like:

+ class
+ class specific message indicator
+ size of data following
+ data

Then the SOLE capture engine is just moving data which is decoded on the
host side.  Each "class" could provide a decode routine.
> 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?
>
See above.
>
>     >
>     > 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?
RTEMS is very different from GNU/Linux or *BSD.  Our memory usage for OS 
objects is
VERY VERY predictable with (by default) hard limits on the number created.

So the memory used by a semaphore is sizeof a struct.
>
>     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.
>
Hopefully this helps you write this up.

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


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