On Mon, Dec 1, 2014 at 7:20 AM, Dominik Taborsky <bre...@seznam.cz> wrote: > On Mon, 01 Dec 2014 01:26:46 +0100, Chris Johns <chr...@rtems.org> wrote: > >> On 1/12/2014 11:15 am, Dominik Taborsky wrote: >>> >>> On Sun, 30 Nov 2014 22:26:18 +0100, Chris Johns <chr...@rtems.org> wrote: >>> >>>> On 1/12/2014 12:17 am, Dominik Taborsky wrote: >>>>> >>>>> On Sun, 30 Nov 2014 01:27:06 +0100, Chris Johns <chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
