Sorry, I clicked on Reply by mistake instead of Reply All. Here is an offline
exchange with Chris.
---
On 10/03/2016 06:39, Vivek Kukreja wrote:
> Hello Chris, Isaac
> I have run the modified hello world example and created a patch for it. I
> cannot access your git server from my institute probably because of some
> firewall issues. I will look into it.
Please keep me posted about the git access.
> Following is the output of diff command:
> --- rtems-4.11.0-rc1master/testsuites/samples/hello/init.c 2015-12-13
> 04:22:53.000000000 -0800
> +++ rtems-4.11.0-rc1/testsuites/samples/hello/init.c 2016-03-09
> 10:35:51.527042759 -0800
> @@ -28,7 +28,7 @@
> )
> {
> rtems_test_begin();
> - printf( "Hello World\n" );
> + printf( "Hello World- Modified by Vivek Kukreja 2016\n" );
> rtems_test_end();
> exit( 0 );
> }
>
The https://devel.rtems.org/wiki/GSoC/GettingStarted pages asks you to
post to the lists your patch and then update the GSoC 2016 page at
https://devel.rtems.org/wiki/GSoC/2016. Can you please do this? Thanks.
>
> I have gone through some recent archives of the IRC and i have some questions:
>
> 1. RTEMS trace linker uses function wrapping to instrument linked files of
> app to interact with capture engine(on-target) and fetching trace data. As
> Isaac has described in this archive
> https://www.mail-archive.com/devel@rtems.org/msg06199.html, barectf is a tool
> used for tracing user-defined data/structs. Is it required and feasible as a
> GSOC project to create support for this feature? As Chris said this would
> require deciding the structure of things a bit.
> Also, can you throw some light on 'target integration' of the capture engine
> with rtems-tld and what tasks does it entail currently?
I have updated the Open Project TraceTool wiki page. Please see have a
look and see if that answers your questions.
> 2. LTTng and barectf support CTF generation. Its required that app/kernel
> files linked using RTEMS trace linker generate either native CTF data or
> trace-data that can be converted to CTF. Could you share some pointers/links
> to understand the current architecture for CTF generation in RTEMS?
Currently there is no CTF support in RTEMS.
> I think this feature has few prerequisites yet many features will use this.
> For example: live trace-reading(over TCP/IP) as Isaac suggested.
Live trace is a function of the back end of the Capture Engine. The
Capture Engine at it's top takes in records from generated by barectf
and buffers them and at it's back end it interfaces to transports to get
the data off the target. This architecture disconnects the transport
from the tracing and allows different transports to be used. For example
it could TCP, or UDP, JTAG, SPI, or a UART. RTEMS users have a wide
range of hardware and often debug interfaces are unique because of the
costs they can add to hardware. Consider a satellite, adding a whole
network interface, MAC and TCP/IP stack to trace during development is
silly because there is no network in space yet all the hardware would
need to be provided for and at a minimum it would take valuable board
space. The key role of the Capture Engine is to provide a simple API for
the transport layers. This work in the Capture Engine is either
partially done or needs to be done.
A key function of the Capture engine is to provide concurrent buffering.
This means low overhead buffering safe in an SMP context. This is harder
than it appears. Keeping it separate from barectf and rtems-tld is
important.
>
> I'm not sure how ambitious these projects are but given a chance i would like
> to work on native CTF generation and live trace-reading with Isaac. Providing
> support for tracing user-defined structs(like barectf) sounds interesting too
> if that feature is required before CTF.
>
These are good GSoC tasks and we welcome your interest in the work.
Chris
_______________
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
