University project - recommendations?

[Dominik Taborsky]

On Sun, 30 Nov 2014 01:27:06 +0100, 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.

OK, I digress.

>
> 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.
>
> Joel and I met three of the EfficiOS people at GSoC this year and  
> discussed this work so we would work with them.
>

So you're working on the capture engine itself, while my job would be to  
compile the trace captured into a CTF, possibly transmitting it over to  
some other machine and decompiling it again?

To make sure, this means implementing some kind of state automata on both  
ends, right?


> 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