<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 2, 2017 at 12:33 PM, Tanu Hari Dixit <span dir="ltr"><<a href="mailto:tokencolour@gmail.com" target="_blank">tokencolour@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andy,<br>
<br>
Joel and Gedare pointed me to the following:<br>
<br>
<a href="https://devel.rtems.org/wiki/Developer/Projects/Open/PythonCoverageReporting" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>Developer/Projects/Open/<wbr>PythonCoverageReporting</a><br>
<a href="https://devel.rtems.org/ticket/2261" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/2261</a><br>
<a href="http://kmiesowicz.blogspot.in/p/esa-socis-2014.html" rel="noreferrer" target="_blank">http://kmiesowicz.blogspot.in/<wbr>p/esa-socis-2014.html</a><br>
<br>
Last link is to the work done by a previous student.<br>
Hope this helps.<br>
My proposal does not take covoar into consideration. Though, I have<br>
planned to produce xml reports from rtems-tester that can be<br>
integrated into coverage testing. Also, I have planned to use this xml<br>
data to get plots (for visualizing results) as a stretch goal (you can<br>
look in the "Future Improvements" Section in my proposal).<br></blockquote><div><br></div><div>covoar directly produces the html and text reports we have now. My</div><div>recollection is that it doesn't have to be touched and that the trick</div><div>is invoking it on a more focused basis than Core vs Developmental.</div><div>So invoke covoar from rtems-tester mulitple times on a single run</div><div>of the tests rather than twice at most.</div><div><br></div><div>Personally, I think Core is still a good description for the core of</div><div>the tasking (e.g. score, rtems, sapi, and posix) and that each</div><div>directory other than that should be individual. But that's my marketing</div><div>view. I could easily be argued that for consistency, it should all</div><div>be on a per directory basis.</div><div><br></div><div>At some point, we might discuss covoar writing a neutral format</div><div>and using Python to do more but that is pure conjecture. I have</div><div>no idea what the intermediate format would be. Writing Sphinx</div><div>output for reports would be desirable from covoar. :)</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Tanu Hari Dixit.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Apr 2, 2017 at 6:50 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
> Joel's e-mail client messed up my reply thread. ;) Andy, have a read<br>
> through <a href="https://gedare.github.io/pdf/FelShe15A.pdf" rel="noreferrer" target="_blank">https://gedare.github.io/pdf/<wbr>FelShe15A.pdf</a> if you haven't<br>
> found it already.<br>
><br>
> Getting qemu-couverture to build via RSB and then integrating the<br>
> coverage scripts into rtems-test, would be a good start to a project.<br>
> There is a student (Tanu)oar dir who has proposed rtems-test improvements, so<br>
> you two would need to coordinate efforts for this piece to avoid too<br>
> much duplicated work/waste. Improvements to the reports etc are also<br>
> welcome, and then of course using the reports to guide code<br>
> refactoring to improve coverage is somewhat open-ended.<br>
><br>
> -Gedare<br>
><br>
> On Sat, Apr 1, 2017 at 9:34 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
>><br>
>><br>
>> On Apr 1, 2017 7:59 PM, "Andy MacGregor" <<a href="mailto:amacgregor.2018@comcast.net">amacgregor.2018@comcast.net</a>><br>
>> wrote:<br>
>><br>
>> On 03/31/2017 09:52 PM, Gedare Bloom wrote:<br>
>><br>
>> Don't forget the deadline is Monday to submit your Final<br>
>> PDF and proof of enrollment. The "Final" PDF can be submitted multiple<br>
>> times, so go ahead and submit it when you finish a first draft. Add<br>
>> your draft proposal to the tracking table at<br>
>> <a href="https://devel.rtems.org/wiki/GSoC/2017" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>GSoC/2017</a> also, to get some possible<br>
>> feedback.<br>
>><br>
>><br>
>> 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<br>
>> 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 broken, so I<br>
>> tried to generate a sample coverage report for 4.12 using ./do_coverage,<br>
>> ./run_coverage and ./coverage_cron as suggested on the wiki here but without<br>
>> 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<br>
>> 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<br>
>> GSOC proposal?<br>
>><br>
>><br>
>> Yes. In fact, the idea was to rework the coverage scripts in shell to be<br>
>> part of the rtems-tester package and in Python. There is some work on this<br>
>> by a previous student which you can find or one of us can dig out. Starting<br>
>> with it, making it work across multiple BSPs, independent of any hard coded<br>
>> paths, improving the output (we did not get far enough that I recall<br>
>> worrying about the quality of the output), etc could be a fair amount of<br>
>> work.<br>
>><br>
>> Also we have privately discussed switching the RSB qemu upstream source to<br>
>> GNATCoverage at GitHub. This is a coverage and embedded focused downstream<br>
>> which includes the coverage trace output I used for the qemu support in<br>
>> covoar. I'm<br>
>><br>
>> In addition, I'd like to actually make some improvements the code coverage<br>
>> itself.<br>
>> The most recent information I could find was these bar graphs from 2009.<br>
>> If these graphs reflect the current coverage state, I think that improving<br>
>> coverage for the i386/pc386,<br>
>> would be interesting because there is room for improvement in both the<br>
>> Baseline and Developmental groups (if these coverage statistics are up to<br>
>> date).<br>
>><br>
>><br>
>> It doesn't matter which BSP you choose for coverage since the code and tests<br>
>> are the same.<br>
>><br>
>> This also reminds me of the other improvements we had wanted. We wanted to<br>
>> switch from Baseline and developmental to a more directory oriented approach<br>
>> for the reports. For example, the reports should be at a granularity of say<br>
>> the Dos file system or shell as reports. The way reports are generated now<br>
>> it results in a skewed view when a large body of code is added to the<br>
>> developmental set. Adding the Dos filesystem resulted in a 15-20% drop in<br>
>> the coverage reported in the Developmental set. That is a bad way to report<br>
>> and misleading. It detracts from the directories which have near 100%<br>
>> coverage.<br>
>><br>
>><br>
>> Does anyone know of a good reason to choose another BSP over i386/pc386?<br>
>><br>
>><br>
>> Users fly the SPARC leon3 and not the pc386. :)<br>
>><br>
>><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.<br>
>><br>
>><br>
>> Dinner time here. Hopefully my feedback makes sense and you can incorporate<br>
>> it.<br>
>><br>
>><br>
>><br>
>><br>
>> -Andy MacGregor<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><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>
>><br>
>><br>
>><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>
> ______________________________<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>
</div></div></blockquote></div><br></div></div>