[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
student for gsoc2008
- Date: Wed, 26 Mar 2008 01:42:18 -0400
- From: alan at fiucssa.org (Reng Zeng)
- Subject: student for gsoc2008
Hi Joel, Chris,
I do not understand your "class" and data along with it below, Could you
please explain it a little more?
That is still TBD. It could be a "class" indicator byte followed by an
event. Something like:
+ class specific message indicator
+ size of data following
For the trace points to add, I understand as below:
1. Write code to generate the wrapped version for each function to trace,
Event_ID eid = Get_Event_ID(symbol);
pass all the arguments to the SOLE handler in capture engine.
together with the data refered by arguments.
p = __real_symbol(size);
pass the return value to the SOLE handler in capture engine.
together with the data refered by return value.
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?
Regarding to other parts of the project, I understand as below, please
1. Transmission of logged data to host
- The first challenge of this part is to make the system and the log
survive from high traffic.
- The second challenge is to implement it in TCP while providing
the flexibility for other transports in future.
- The third challenge is to trade off minimizing the data to be
sent across the network against the over-head to compress data.
2. Receipt of logged data on host
- Use Python to write a CLI to receive data into a file.
3. Decoding of logged data on host
- From the compressed data received, decode it for high-level
application to display as tracing data.
4. GUI Timeline Visualization tool
- Use GNUplot to integrate the decoded data into visualization format.
What kind of visualization is expected?
2008/3/23, Joel Sherrill <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.
-------------- next part --------------
An HTML attachment was scrubbed...