GSoC 2017 -- initial proof

[Joel Sherrill]

On Apr 1, 2017 7:59 PM, "Andy MacGregor" <amacgregor.2018 at comcast.net>
wrote:

On 03/31/2017 09:52 PM, Gedare Bloom wrote:

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
athttps://devel.rtems.org/wiki/GSoC/2017 also, to get some possible
feedback.



Thanks for the welcome! (I realize I am late to the GSOC application table).

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.

The link on the wiki to the current code status is currently broken
<https://www.rtems.org/ftp/pub/rtems/people/joel/coverage/>, 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 here
<https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis#HowitisDoneNow>but
without any luck. Is there an up to date coverage report available?
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.

Could updating these coverage analysis scripts be a viable component of a
GSOC proposal?


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.

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

In addition, I'd like to actually make some improvements the code coverage
itself.
The most recent information I could find was these bar graphs from 2009.
<https://devel.rtems.org/wiki/Developer/Coverage/Status>
If these graphs reflect the current coverage state, I think that improving
coverage for the i386/pc386,
would be interesting because there is room for improvement in both the
Baseline and Developmental groups (if these coverage statistics are up to
date).


It doesn't matter which BSP you choose for coverage since the code and
tests are the same.

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.


Does anyone know of a good reason to choose another BSP over i386/pc386?


Users fly the SPARC leon3 and not the pc386. :)


I've just posted a draft of my proposal to the GSOC page.
If there's any feedback I'll be sure to update my proposal in time.


Dinner time here. Hopefully my feedback makes sense and you can incorporate
it.




-Andy MacGregor










_______________________________________________
devel mailing list
devel at rtems.org
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170401/0acb8b1f/attachment.html>