On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > Hello Vidushi, > > On 29/06/18 09:44, Vidushi Vashishth wrote: >> >> >> >Could you please create a self-contained repository which >> contains >> >> >* a README >> >> >* a simple RTEMS application which runs on a simulator BSP >> >> >* the stuff that makes it possible to view the trace output >> (it is not a problem if it doesn't work, but all pieces should >> be included) >> >> >The repository should not be a clone of some larger project. >> It may contain external references as submodules. >> >> Okay. Got it. I will update you when its done. >> >> >> Ok, do you have a time estimate for this? Which parts are missing? >> >> >> Viewing the trace output is buggy right now. I will have to combine the >> rest. I will push the required things in the repository by end of today and >> notify you. >> > > the stuff you published here > > https://github.com/VidushiVashishth/Tracing > > yesterday (this is not "by end of today") is not much considering this the > 8th week of the GSoC project. > > You seem to have imported cpukit/libmisc/shell/main_rtrace.c and modified > it. The modifications are not visible in the repository history. Why did yo > copy this file out of the RTEMS sources at all? > > There is no Makefile (or similar). You have to read the documentation to > build it. You cannot copy and past the instructions to build it since it > contains your local paths. > > The test data is generated with user input. > > How can I transfer the test data generated on the simulator to my host > development system? > > I asked for a self-contained repository, with"the stuff that makes it > possible to view the trace output". This is missing. > > Could you please: > > 1. Not copy sources out of the RTEMS repository. Before you do this, ask on > the mailing list and explain why have have to do it. > > 2. If you import things, then import the original files and state the > origin. > > 3. Clearly document your modifications in separate commit messages. > > 4. Add a Makefile to build it automatically. > > 5. Add the missing stuff that makes it possible to view the trace output. If > something is not available yet, then no problem. Just document the > interfaces and what it is supposed to do. > > 6. Document the steps involved in the tracing, e.g. trace data generation on > the RTEMS target, transfer of the data to the development host, conversion > of trace data in format X to Y using tool Z, etc. Document the interfaces > between the different steps and what runs on the RTEMS target and what runs > on the development host. > > To get the trace data from the simulator to the development host, you can > just dump the data via printf() and parse it on the host. This is slow, but > enough for a test scenario. > > You should be able to do this in a couple of hours. >
I'm trying to catch up. I generally agree with all this. Also, I do not see any reason ever to try to run babeltrace from RTEMS. I don't know if that is being attempted, but it is not a worthwhile effort. Either we should use barectf to generate CTF traces in RTEMS, we should implement our own CTF generator in RTEMS, or we should provide a converter for running babeltrace on a host (Linux/MacOS/etc) to convert from RTEMS trace linker format to CTF. Gedare > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
