University project - recommendations?

[Joel Sherrill]

On November 29, 2014 6:27:06 PM CST, Chris Johns <chrisj at rtems.org> wrote:
>On 29/11/2014 11:14 pm, Dominik Taborsky wrote:
>> On Sat, 29 Nov 2014 04:44:53 +0100, Gedare Bloom <gedare at rtems.org>
>wrote:
>>
>>> On Fri, Nov 28, 2014 at 4:17 PM, Dominik Taborsky <bremby at seznam.cz>
>>> wrote:
>>>> I have browsed through the wiki/trac and I found these 3:
>>>> 1) CFI-standard flash device interface,
>>>> 2) CEXP integration,
>>>> 3) TCP stack rewrite.
>>>>
>>> I don't know that CEXP integration is that interesting anymore. One
>of
>>> the key features of CEXP is dynamic loading, which is not supported
>>> through the RTEMS linker and loader projects (RTL). You might ask
>>> Chris Johns if there are projects available for RTL.
>>
>> Chris is subscribed to this ML so he can reply now. Or should I
>address
>> him directly?
>>
>
>Here is fine and welcome to RTEMS.
>
>The RTL is in the main tree now under libld. There are some extra tasks
>
>to complete, one relate to ARM veneers and adding veneer support in 
>general that is outstanding but I am not sure there is enough work left
>
>in them for you. The veneer is an interesting task and has some
>challengers.
>
>One area that has plenty of work that needs doing plus ways to innovate
>
>is trace. Jennifer is adding trace support to the capture engine [1]
>for 
>SMP and I have written a trace linker [2] that has support to trace 
>calls using printk. We need to hook all this together to make a
>workable 
>solution for users and we are currently looking at the Common Trace 
>Format (CTF) [3] to do this. Generating CTF lets us integrate with 
>Babletrace and the Linux Trace Toolkit Viewer (LTTV).
>
>The trace support we are adding attempts to solve some tough user 
>requirements from the space community such as instrumenting and tracing
>
>software at the object level rather than instrumenting at the source 
>level. This means you take software that is compiled and production 
>ready and link in trace support. The support needs to be efficient 
>because it is a target side software only trace. Transporting data off 
>target needs to be generic and flexible because we have so many 
>different target types with differing hardware.
>
>The work involves adding suitable support to the capture engine to 
>extract the trace data and convert it to the CTF format. This may be on
>
>target or off target depending on the load it places on the target. We 
>have lots of pieces of code in place but the code is new and green so 
>you would need to work across all parts. We need support for generating
>
>trigger and trace control maps and this may be linked to the CTF format
>
>and Babeltrace. There will be work at real-time capture level, the
>trace 
>linking parts on the host, and CTF integrations.

And even as good as this description is, there needs to be work on defining how the use can set triggers and filters so the data captured does not flood the target.

Plus we have not discussed any details of an agent on the target which could feed live traces, be asked questions about the running system like memory and cpu usage, etc. 

There are lots of details but the end result can leverage GUI tools that exist and provide an impressive user experience.



>
>Joel and I met three of the EfficiOS people at GSoC this year and 
>discussed this work so we would work with them.
>
>Chris
>
>[1] https://devel.rtems.org/browser/rtems/cpukit/libmisc/capture
>[2] https://devel.rtems.org/browser/rtems-tools/linkers/rtems-tld.cpp
>[3] http://www.efficios.com/ctf
>_______________________________________________
>devel mailing list
>devel at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel

--joel