<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Apr 1, 2017 7:59 PM, "Andy MacGregor" <<a href="mailto:amacgregor.2018@comcast.net">amacgregor.2018@comcast.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="quoted-text">
<div class="m_8115129114194600535moz-cite-prefix">On 03/31/2017 09:52 PM, Gedare Bloom
wrote:<br>
</div>
<blockquote type="cite">
<pre>Don't forget the deadline is Monday to submit your Final
PDF and proof of enrollment. The "Final" PDF can be submitted multiple
times, so go ahead and submit it when you finish a first draft. Add
your draft proposal to the tracking table at
<a class="m_8115129114194600535moz-txt-link-freetext" href="https://devel.rtems.org/wiki/GSoC/2017" target="_blank">https://devel.rtems.org/wiki/<wbr>GSoC/2017</a> also, to get some possible
feedback.
</pre>
</blockquote>
<br></div>
Thanks for the welcome! (I realize I am late to the GSOC application
table).<br>
<br>
I'm set on improving code coverage of the testsuite, but I found
some questions as I'm starting to look into how its done.<br>
<br>
The link on the wiki to the current code status is currently <a href="https://www.rtems.org/ftp/pub/rtems/people/joel/coverage/" target="_blank">broken</a>,
so I tried to generate a sample coverage report for 4.12 using
./do_coverage, ./run_coverage and ./coverage_cron as suggested on
the wiki <a href="https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis#HowitisDoneNow" target="_blank">here
</a>but without any luck. Is there an up to date coverage report
available?<br>
I modified the VERSIONS-COVERAGE file like the wiki said, and once
that didn't work dug around in the script but fix it myself quickly.<br>
<br>
Could updating these coverage analysis scripts be a viable component
of a GSOC proposal?<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Yes. In fact, the idea was to rework the coverage scripts in shell to be part of the rtems-tester package and in Python. There is some work on this by a previous student which you can find or one of us can dig out. Starting with it, making it work across multiple BSPs, independent of any hard coded paths, improving the output (we did not get far enough that I recall worrying about the quality of the output), etc could be a fair amount of work.</div><div dir="auto"><br></div><div dir="auto">Also we have privately discussed switching the RSB qemu upstream source to GNATCoverage at GitHub. This is a coverage and embedded focused downstream which includes​ the coverage trace output I used for the qemu support in covoar. I'm</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
In addition, I'd like to actually make some improvements the code
coverage itself.<br>
The most recent information I could find was these bar graphs from <a href="https://devel.rtems.org/wiki/Developer/Coverage/Status" target="_blank">2009.</a><br>
If these graphs reflect the current coverage state, I think that
improving coverage for the i386/pc386, <br>
would be interesting because there is room for improvement in both
the Baseline and Developmental groups (if these coverage statistics
are up to date).<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">It doesn't matter which BSP you choose for coverage since the code and tests are the same.</div><div dir="auto"><br></div><div dir="auto">This also reminds me of the other improvements we had wanted. We wanted to switch from Baseline and developmental to a more directory oriented approach for the reports. For example, the reports should be at a granularity of say the Dos file system or shell as reports. The way reports are generated now it results in a skewed view when a large body of code is added to the developmental set. Adding the Dos filesystem resulted in a 15-20% drop in the coverage reported in the Developmental set. That is a bad way to report and misleading. It detracts from the directories which have near 100% coverage.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Does anyone know of a good reason to choose another BSP over
i386/pc386?<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Users fly the SPARC leon3 and not the pc386. :)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
I've just posted a draft of my proposal to the GSOC page. <br>
If there's any feedback I'll be sure to update my proposal in time.</div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Dinner time here. Hopefully my feedback makes sense and you can incorporate it.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><font color="#888888"><br>
<br>
-Andy MacGregor<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></div>
<br>______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div></div></div>