[RTEMS Project] #3696: Basic Support for Trace Compass

[RTEMS trac]

#3696: Basic Support for Trace Compass
------------------------------+-----------------------------
  Reporter:  Sebastian Huber  |      Owner:  Sebastian Huber
      Type:  project          |     Status:  assigned
  Priority:  normal           |  Milestone:
 Component:  tool             |    Version:
  Severity:  normal           |   Keywords:  GSoC
Blocked By:                   |   Blocking:
------------------------------+-----------------------------
 The [https://www.eclipse.org/tracecompass/ Trace Compass] is a tool to
 analyse and display trace data. Trace data can be gathered from RTEMS
 applications via various means, for example:
 * [https://docs.rtems.org/branches/master/user/tracing/tracelinker.html
 RTEMS Trace Linker]
 * [https://docs.rtems.org/branches/master/user/tracing/eventrecording.html
 Event Recording]
 * [https://docs.rtems.org/branches/master/user/tracing/captureengine.html
 Capture Engine]

 The goal of this project is to enable the Trace Compass to analyse and
 display some basic information using the Event Recording infrastructure.
 Basic information is defined by the Linux kernel trace support (lttng) and
 includes (see Trace Compass project explorer Tracing -> Traces ->
 Something):

 * kernel
  * Views
   * CPU usage
    * CPU usage
   * IRQ Analysis
    * IRQ Statistics
    * IRQ Table
    * IRQ vs Count
    * IRQ vs Time
   * Linux Kernel
    * Control Flow
    * Resources

 Example data can be obtained from the
 [https://github.com/tuxology/tracevizlab Trace Visualization Labs].

 Advanced support for Trace Compass could include dynamic memory traces,
 stack usage, network packet flow, etc.

 There are four main problems.

 1. Generation of sufficient trace events, currently the interrupt
 entry/exit events are not available for example.

 2. The trace data must be transferred from the target system running the
 RTEMS application to a host computer running the Trace Compass (transfer
 via TCP is available, for UDP based transfer see #3695).

 3. The Trace Compass must be able to analyse and display the information
 obtained from the Event Recording.

 4. The RTEMS user must be able to use this infrastructure.  This requires
 that it is easy to use, availability of tutorials and documentation.

 To tackle problem 3. there are two approaches possible. You can extend the
 Trace Compass to work with the trace data provided by RTEMS as is.
 Alternatively, the RTEMS trace data could be converted to Linux kernel
 trace data (lttng) which Trace Compass already understands.

 Related topics are [https://diamon.org/ctf/ Common Trace Format],
 [https://diamon.org/babeltrace/ Babeltrace],
 [https://github.com/efficios/barectf barectf], #2961 and #3028.

 **Skills Needed**

 You need good C and C++ skills with a proven record. You need to show
 socket level and networking programming skills. In case Trace Compass
 needs to be extended this requires Java skills and familiarity with the
 Eclipse framework. Knowledge of YAML and XML is helpful. High end RTEMS
 targets can generate a huge number of events per second (10MiB/s trace
 data is 1310720 events per second; on a 4GHz host processor this is 3051
 instructions per event under real-time processing conditions) which
 imposes a considerable work load to modern host computers, so the host
 programs must work efficiently.

 **Difficulty**

 We consider this an advanced project.

--
Ticket URL: <http://devel.rtems.org/ticket/3696>
RTEMS Project <http://www.rtems.org/>
RTEMS Project