[PATCH v2] rtems-record: New program

[Sebastian Huber]

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

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

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

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.