[PATCH v2] rtems-record: New program

[Chris Johns]

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?

>> 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.

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?

> When we think about C++, then we should also think about boost, but this is
> another topic.

Yes this is off topic. Boost is great, there is no issue here. It's leadership
role in C++ is impressive. I am however unlikely to agree to adding boost to
rtems-tools as source unless there is a compelling reason. MacOS's Xcode does
not seem to contain boost headers by default and I have not check MSYS2 mingw
support. The C++ standards have so far proved to be portable and predicable
across different hosts and compilers with no extra effort from us.

Chris