----- Am 15. Aug 2019 um 2:09 schrieb Chris Johns chr...@rtems.org: > On 14/8/19 3:19 pm, Sebastian Huber wrote: >> On 14/08/2019 03:57, Chris Johns wrote: >>> On 13/8/19 3:10 pm, Sebastian Huber wrote: >>>> sorry for the rush, >>> >>> Sorry for the delay, I have a client demo this week I am helping with. >>> >>>> but what do you think of this patch? >>> >>> Why not C++? The rtems-tools repo has strong support for C++ and it brings a >>> range of benefits, for example no need to code call handlers at a low level, >>> containers so no need for us to include and maintain trace/record/tree.h, >>> and >>> more. When I see us adding code like `tree.h` I have in the back of my mind >>> the >>> long term support issues it brings while a `std::map` is maintained for us. >> >> Originally, the program should be able to filter live traces with about >> 20MiB/s. >> The std::map is simply too slow. > > It is difficult to comment without us heading into detail and I do not think > there is any value in doing that. > >> Boost.Intrusive would be an option (it is >> slower than tree.h in my tests too: https://github.com/sebhub/rb-bench). The >> tree.h is a copy from Newlib, so it doesn't introduce new maintenance issues. >> Anyway, for the CTF conversion the map is unnecessary and could be optimized >> away. We didn't had the time to do this in the GSoC project. > > So performance is not an issue here and the code's presence is historical?
Ravindra needs this patch to integrate his work on top of it. I posted this patch on January and at this time using C was not an issue: https://lists.rtems.org/pipermail/devel/2019-January/024640.html His integration is now blocked because of something he didn't cause. > >>> GNU projects like gdb and gcc have moved to C++ and of course llvm is C++ >>> and >>> this is for good reason. I provide these examples in the hope this does not >>> start a C vs C++ debate. >>> >>>> I would like to >>>> integrate the tracing work of the GSoC project and this patch is a blocking >>>> point. >>> >>> I understand. I am excited by the work that has been done here and what you >>> are >>> doing. It is taking all my will power to not read the ARM debug trace >>> section of >>> an ARM TRM as I think that hardware is ripe for integration with this code >>> base >>> and set of tools. A C++ framework in rtemstoolkit would be really helpful >>> if I >>> do as it would grow what we have rather than us collecting isolated C >>> programs. >>> >>> I also understand and appreciate the limited time we all have so I am happy >>> to >>> hear how you see the host side progressing over time and how it fits into >>> our >>> ecosystem. I would also like to hear what others think. >> >> I don't have a problem with C++ in general. However, I don't think that the >> use >> of C in this small program is a blocking point to integrate the GSoC work. >> This is work in progress anyway. This program only scratches the surface. > > What parts are to be added that depend on this tool? Maybe it would help if > this > is presented. > > Work in progress pieces are fine if there is a progression however I did state > at the start of GSoC we currently use python and C++. I am weary of isolated > tools that become unclear if we need to keep or we can remove after a period > of > time. Sorry, but you should have stated that C++ is mandatory a bit earlier. Now it is difficult to change. Ravindra did his work on top of a C program. We can easily convert it to C++, but only after the integration of Ravindra's work. The tool is already useful, it converts the RTEMS record stream into a CTF stream which can be read by Trace Compass to display the thread switches on multiple CPUs and the CPU utilization. > > Tools added to rtems-tools and installed are public facing user interfaces to > our users. By installing the RTEMS project is agreeing to provide and support > the interface provided. I am fine with tools being add if they serve other > roles, for example as a means to test rtemstoolkit code, ie regression and > development test tools. It is unclear to me where this tool fits. > > Maybe we need an option to rtems-tools's configure such as --experimental that > builds and installs tools that are a work in progress but are not a public > interface? Ok, sorry, I should have started with the integration planning of the GSoC work a bit earlier. Ravindara, I added a now branch to your repository: https://github.com/rmeena840/rtems-tools/tree/ravindra-record-ctf It is a rebase of your work to the current rtems-tools master with all your commits squashed into one. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel