student for gsoc2008

[Joel Sherrill]

Reng Zeng wrote:
> Hi Joel, Chris,
>
> I do not understand your "class" and data along with it below, Could 
> you please explain it a little more?
>
Did my separate post help?
> 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
>
> For the trace points to add, I understand as below:
>
> 1. Write code to generate the wrapped version for each function to 
> trace, such as
> void *__wrap_symbol(arguments)
> {
>   void *p;
>   void *__real_symbol(arguments);
>
>   Event_ID eid = Get_Event_ID(symbol);
>  
>   if (TriggerSet(eid))
>          pass all the arguments to the SOLE handler in capture engine.
>          together with the data refered by arguments.
>      
>   p = __real_symbol(size);
>  
>   if (TriggerSet(eid))
>       pass the return value to the SOLE handler in capture engine.
>     together with the data refered by return value.
>  
>   return p;
> }
I wish Chris was back from his honeymoon.

But as far I understand that is generally correct.  You want to log entry
and exit status from every wrapped call. 

I believe Chris has an idea where the trigger is actually in the capture
engine and users can provide boolean expressions.  Greatly simplifies
the logging.

Plus with the wrapping idea, you turn the wrapper completely off via
ld arguments.  That part can be done manually or via a GUI to generate
a file that is passed to the ld command line.
>
> 2. Triggers are to be managed by the event ID.
>
> 3. I has no idea about the filter for these events. For existing task 
> related one, we could filter by priority, but how about the wrapped 
> one? Could you tell some example for me to consider?
>
Based upon the id of the executing thread. Try this example:

log all semaphore manager calls for thread 32.
log all context switches
log all malloc/free calls for thread 75.

Start tracing after 10 seconds and log for 15 seconds.
> Regarding to other parts of the project, I understand as below, please 
> comment.
> 1. Transmission of logged data to host
>
>           o The first challenge of this part is to make the system and
>             the log survive from high traffic.
>           o The second challenge is to implement it in TCP while
>             providing the flexibility for other transports in future.
>           o The third challenge is to trade off minimizing the data to
>             be sent across the network against the over-head to
>             compress data.
>
Right.  This is something to investigate and do the trade-offs in the 
early phase of
the project.

The "communications transport" code must be pluggable and replaceable
byu the user.  This simplifies your job because a simple TCP stream could
be the first implementation.  Leaving it as a plugin point, lets it be 
changed
by a user or a subsequent developer.  You provide a baseline.
>
> 2. Receipt of logged data on host
>
>           o Use Python to write a CLI to receive data into a file.
>
That's the first step. You have to receive the raw log data.

Chris is a Python fan.. I am concerned about the functionality.  If python
makes it easier, so be it.  It does make it portable to other hosts.
> 3. Decoding of logged data on host
>
>           o From the compressed data received, decode it for
>             high-level application to display as tracing data.
>
Right.  Next step.. an ascii dump.  Not pretty but accurate. 
>
> 4. GUI Timeline Visualization tool
>
>           o Use GNUplot to integrate the decoded data into
>             visualization format. What kind of visualization is expected?
>
>
You don't have to use GNUplot and you might not even get to this phase.  
There
is likely a lot of work to do.

The Linux Trace Toolkit, WindView, and Spyker are similar tools for other
OSes.  Take a look at them.  I know Skyker has a scrolling timeline type
interface where you are kind of reading an "EKG" type look at system
events marked on the timeline.
> Thanks,
> Alan
>
>
> 2008/3/23, Joel Sherrill <joel.sherrill at oarcorp.com 
> <mailto:joel.sherrill at oarcorp.com>>:
>
>     > [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.
>
>


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