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:
On 29/11/2014 11:14 pm, Dominik Taborsky wrote:
On Sat, 29 Nov 2014 04:44:53 +0100, Gedare Bloom <ged...@rtems.org>
wrote:
On Fri, Nov 28, 2014 at 4:17 PM, Dominik Taborsky <bre...@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,
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 the
upstream project.
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.
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.
Chris
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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
