<div dir="ltr">hi!<div><br></div><div><font color="#351c75">> <span style="font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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.</span></font></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px">Currently I plan to deliver a barectf integrated RTEMS trace linker and a transport mechanism to deliver trace data to the host machine using TCP by mid term evaluation (second phase). I intend to fix any errors encountered in the process by end of second phase itself. I understand how kernel level tracing will be beneficial to the tracing framework. I can modify my proposal to include this as one of my goals. I also intend to deliver live tracing functionality as a goal of my third phase. Would it be viable to accommodate kernel level tracing to my current plan? Or should I discount any of my current goals (integration of barectf, transport mechanism to host, live tracing) in place of it?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards,</span></div><div><span style="font-size:12.8px">Vidushi Vashishth</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 12:17 PM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 23/03/18 16:28, Gedare Bloom wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Vidushi, Sebastian:<br>
<br>
On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brai<wbr>ns.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Vidushi,<br>
<br>
the RTEMS Trace Linker is definitely an interesting tool to track down<br>
difficult and specific issues. However, this is a nice to have optional<br>
</blockquote>
out-of-box Trace Linker with integration to debugger or CTF tools will<br>
be highly beneficial for the "user-side" experience of RTEMS. This can<br>
be quite beneficial for marketing if nothing else. :) Given the<br>
current state, and that we've had a few projects already on this<br>
topic, any project working here needs to focus on delivering a<br>
complete slice of the software stack from trace configuration all the<br>
way through trace output analysis. There is a lot to review to get the<br>
plan right here. I've made comments on the google doc proposal.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
feature from my point of view. We should focus on basic functionality and<br>
this is interrupt entry/exit and thread switching. This should work out of<br>
the box without having to compile RTEMS with specialized configuration<br>
</blockquote>
I agree that this is also an important aspect for "kernel-level"<br>
tracing, and it should be implemented directly into RTEMS with<br>
standard configuration (configure or confdefs.h options). The<br>
requirements for this functionality is unclear, though, such as what<br>
the trace output should be.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
options. It should work via a serial line and network (UDP I guess). It<br>
</blockquote>
I don't see how network support can exist out-of-the-box unless the<br>
solution exists at libbsd level. I think there will be two pieces to<br>
this kind of project:<br>
1. capturing traces to memory buffers from interrupt/"kernel" contexts.<br>
2. transporting buffers via worker threads.<br>
<br>
Then, one can implement a basic worker thread using available drivers<br>
in rtems, and also more advanced (network) workers relying on libbsd.<br>
</blockquote>
<br></span>
The network transport should rely on the POSIX sockets API only as defined by Newlib.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
should also support SMP machines. This requires per-processor trace buffers.<br>
The trace buffer should work without locks, e.g. only interrupt<br>
disable/enable. I would do also a short review of existing trace solutions.<br>
</blockquote>
The use of per-processor buffers makes the "reader" side (transport)<br>
more complicated. This is a good place to consider a wait-free<br>
non-blocking data structure, or a rwlock with writer prioritization.<br>
At any rate, a good design is needed here with some careful thought.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe we don't have to re-invent the wheel. For example:<br>
<br>
<a href="http://www.cs.unc.edu/~bbb/feathertrace/" rel="noreferrer" target="_blank">http://www.cs.unc.edu/~bbb/fea<wbr>thertrace/</a><br>
</blockquote></blockquote>
<br></span>
This was just one example.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brain<wbr>s.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</div></div></blockquote></div><br></div>