On 23/03/18 16:28, Gedare Bloom wrote:
Hello Vidushi, Sebastian:
On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
Hello Vidushi,
the RTEMS Trace Linker is definitely an interesting tool to track down
difficult and specific issues. However, this is a nice to have optional
out-of-box Trace Linker with integration to debugger or CTF tools will
be highly beneficial for the "user-side" experience of RTEMS. This can
be quite beneficial for marketing if nothing else. :) Given the
current state, and that we've had a few projects already on this
topic, any project working here needs to focus on delivering a
complete slice of the software stack from trace configuration all the
way through trace output analysis. There is a lot to review to get the
plan right here. I've made comments on the google doc proposal.
I think we should define some basic functionality which should be
available ready to use during mid term evaluation. I want to avoid a
last minute delivery during the project end with no time to fix problems
after a review. This likely results in some half-finished work which
nobody can use.
feature from my point of view. We should focus on basic functionality and
this is interrupt entry/exit and thread switching. This should work out of
the box without having to compile RTEMS with specialized configuration
I agree that this is also an important aspect for "kernel-level"
tracing, and it should be implemented directly into RTEMS with
standard configuration (configure or confdefs.h options). The
requirements for this functionality is unclear, though, such as what
the trace output should be.
options. It should work via a serial line and network (UDP I guess). It
I don't see how network support can exist out-of-the-box unless the
solution exists at libbsd level. I think there will be two pieces to
this kind of project:
1. capturing traces to memory buffers from interrupt/"kernel" contexts.
2. transporting buffers via worker threads.
Then, one can implement a basic worker thread using available drivers
in rtems, and also more advanced (network) workers relying on libbsd.
The network transport should rely on the POSIX sockets API only as
defined by Newlib.
should also support SMP machines. This requires per-processor trace buffers.
The trace buffer should work without locks, e.g. only interrupt
disable/enable. I would do also a short review of existing trace solutions.
The use of per-processor buffers makes the "reader" side (transport)
more complicated. This is a good place to consider a wait-free
non-blocking data structure, or a rwlock with writer prioritization.
At any rate, a good design is needed here with some careful thought.
Everything which uses an atomic read-modify-write operation on some
global data will lead to a significant change in the overall timing on
larger machines with several cache layers (e.g. QoriIQ T4240). The
reader side with per-processor data is not that difficult if everything
runs in kernel-space. You can use processor affine threads (supported by
the default SMP scheduler) or inter-processor interrupts to fetch the data.
Maybe we don't have to re-invent the wheel. For example:
http://www.cs.unc.edu/~bbb/feathertrace/
This was just one example.
--
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
