[PATCH v2] rtems-record: New program

[Sebastian Huber]

----- Am 15. Aug 2019 um 2:09 schrieb Chris Johns chrisj at 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.