Changes between Version 122 and Version 123 of Developer/OpenProjects

Timestamp:

Apr 1, 2009, 8:54:04 AM (12 years ago)

Author:

ChrisJohns

Comment:

Update the task list.

Developer/OpenProjects

@@ -84 +84 @@
  *  GUI Timeline Visualization tool
 
-Chris and Joel have done some initial work and prototyping has been done on the first four parts. Chris wrote the capture engine and this is currently part of RTEMS. The purpose was to look at performance issues relating to filtering, triggering, and storage of events ready for transmission to a host. Together Chris and Joel believe that the bulk of the work adding trace points can be done automatically using the GNU ld "wrap capability" given a user generated list of trace points. The first stage of this task is to extract function signatures from existing libraries then match against the requested list of trace points to generate the wrap code module for the target. The next stage is to integrate this code module with the existing capture engine to allow filtering and triggering. The implementation needs to keep overheads as low as possible and to manage the threading issues that are present in this area of the code. A key requirement is not to change any code in the libraries being traced.
+The requirements of the Run-Time tracing is to provide a common means audit an RTEMS application for conformance of input/output parameters and/or timing, or to debug an application. The auditing process typically uses a static configuration the user manages. The debugging process usually targets a standard set of calls such as the RTEMS Classic API and uses dynamic filtering to control what is looked at as the debugging session unfolds.
+
+Chris and Joel have done some initial work and prototyping has been done on the first four parts. Chris wrote the capture engine and this is currently part of RTEMS ([wiki:TBR/UserManual/Capture_Engine Capture Engine]). The purpose was to look at performance issues relating to filtering, triggering, and storage of events ready for transmission to a host. Together Chris and Joel believe that the bulk of the work adding trace points can be done automatically using the GNU ld "wrap capability" given a user generated list of trace points. The first stage of this task is to extract function signatures from existing libraries then match against the requested list of trace points to generate the wrap code module for the target. Extracting a signature lowers the on going maintenance of the signature as the tool will always match the library being traced. The next stage is to integrate this code module with the existing capture engine to allow filtering and triggering. The implementation needs to keep overheads as low as possible and to manage the threading issues that are present in this area of the code. A key requirement is not to change any code in the libraries being traced.
 
 In addition, we believe a simple text dump of the trace log on the host side can be derived in a highly automated manner. The code to transmit data from the RTEMS system and to receive the data on the host computer will have to be written. The design of the target transmit code needs to be flexible to allow for a wide range of possible transports. The first and most common transport will be TCP and this needs to be implemented. The target code needs to carefully consider stability issues. A tracing system such as this can generate more data than the transport can handle. The design needs to trade off an efficient protocol that minimizes the data sent against adding too much overhead compressing data. The host side to receive the data needs to be portable across all popular host operating systems. The preferred language is Python. The receive code can be a command line tool to save the data to a file or it could form part of a larger program. This code can become the glue between the target data and existing host applications designed to display trace data.
@@ -91 +93 @@
 
 Greg Menke of NASA has used GNU plot to do a simple version of this and may have advice.
+
+The 2008 GSoC project dealt with the function signature extraction and generating trace code. There is also code to write a trace log to the file system. This file can be exported to a host machine for analysis by a number of available means such as flash cards, hard disk, NFS or some other network protocol. This year the GSoC project needs to:
+
+# Take the existing code and create a suitable patch for CVS.
+# Consolidate how a traceable application is created making the process as simple and transparent for the user as it can be.
+# Look at the addition of dynamic filtering and triggering. This is complicated by the handling of the event ids allocated to a specific trace point.
 = Implement POSIX Asynchronous and List IO =