CTF: University project

[Gedare Bloom]

On Mon, Dec 1, 2014 at 7:20 AM, Dominik Taborsky <bremby at seznam.cz> wrote:
> On Mon, 01 Dec 2014 01:26:46 +0100, Chris Johns <chrisj at rtems.org> wrote:
>
>> On 1/12/2014 11:15 am, Dominik Taborsky wrote:
>>>
>>> On Sun, 30 Nov 2014 22:26:18 +0100, Chris Johns <chrisj at rtems.org> wrote:
>>>
>>>> On 1/12/2014 12:17 am, Dominik Taborsky wrote:
>>>>>
>>>>> On Sun, 30 Nov 2014 01:27:06 +0100, Chris Johns <chrisj at rtems.org>
>>>>> wrote:
>>>
>>>
>>> ...
>>>
>>>>>>
>>>>>> 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,
>>>>
>>>>
>>>> I am not but Jennifer is. I am not sure what remaining work she has
>>>> planned. I have been doing little bits with the trace linker and that
>>>> code needs work to integrate with the capture engine. For example
>>>> trigger maps plus other controls.
>>>>
>>>>> while my job would be to compile the trace captured into a CTF,
>>>>
>>>>
>>>> If you are lucky this might be the case. How we integrate to that code
>>>> base has not been looked at. Using this format lets us use the nice
>>>> front end tools that exist. Any changes will require us working with
>>>> theupstream project.
>>>
>>>
>>> I'm not planning to change it, after my blitz look at it, it seems very
>>> comprehensive.
>>>
>>>>
>>>>> possibly transmitting it over to some other machine and decompiling
>>>>> it again?
>>>>
>>>>
>>>> Yes these tasks exist. The transmission task is complex because of the
>>>> possible overhead it can create. As Joel said we need to create
>>>> trigger maps and merge them into the system some how plus there are
>>>> possible stability issues where the trace overloads the target to be
>>>> considered.
>>>
>>>
>>> These are implementation details, right now I worry about design, i.e.
>>> what am I supposed to do... :)
>>>
>>>>
>>>> The capture engine has 2 parts, the capture part and a command line
>>>> interface via the RTEMS shell. This work relates to just the capture
>>>> engine code and not the CLI.
>>>>
>>>>>
>>>>> To make sure, this means implementing some kind of state automata on
>>>>> both ends, right?
>>>>>
>>>>
>>>> I am not sure this process is that exact.
>>>
>>>
>>> It seems to me like that, but let's skip that for now.
>>>
>>>
>>> Right now I worry about my goals. I need to give my teacher some kind of
>>> roadmap what I'll be doing. After that I'll dive into the code.
>>
>>
>> I understand and this make sense.
>>
>>>
>>> I need a milestone to achieve during February and then possibly another
>>> during June. Can you select one milestone for February using an educated
>>> guess what could be achieved, perhaps only as alpha version? I just need
>>> something to aim at.
>>
>>
>> Yes I think we can do this.
>>
>>>
>>> Thanks for your patience with me, Chris! :)
>>>
>>
>> No need to thank me, it is us who should thank you for taking an interest.
>>
>> Let me think about the specifics. I will look into babletrace some more to
>> see how we would interface. I am happy to take the specifics of a timeline
>> for you off line with Gedare and Joel. How does that sound ?
>
>
> You mean you want to discuss the specifics in person with Gedare and Joel?
> I'm not sure I understand. But if so, I agree.
>
He means we can discuss the timetable without the rest of the mailing
list involved. I'm good with that.

 -Gedare

>>
>> Chris