<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 5, 2018, 10:21 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/6/18 9:13 am, Joel Sherrill wrote:<br>
> Just chatted with Chris. The coverage BSP ini file was a temporary<br>
> measure as I thought. <br>
<br>
I may have not understood the specific issue being discussed when we talked.<br>
<br>
I separated the INI files because this is what we do else where (see the leon3<br>
example below). I consider options as a way to vary the default behavior so the<br>
less we have the better. A default run without extra options is preferred.<br>
<br>
You cannot add --coverage to all supported BSPs and get coverage and for this<br>
option to be useful this is what the option should do. To control coverage you<br>
need to know it can be supported so the question becomes simple, if you can do<br>
coverage why would you decide not too? In other words 'leon3-qemu-cov' should<br>
not need a --coverage option unless you wish to change the sets used and that is<br>
varying the default behavior.<br>
<br>
For example you can run leon3 with:<br>
<br>
 leon3<br>
 leon3-qemu-cov<br>
 leon3-qemu<br>
 leon3-run<br>
 leon3-sis<br>
 leon3_tsim<br>
 leon3_tsim-run<br>
 leon3-tsim-cmds<br>
<br>
and we do not have options to manage any of these differences line 'tsim' so why<br>
is coverage being treated as something special? To me it is not.<br>
<br>
The separation was on purpose and for this reason and not temporary. The changes<br>
needed to have this happen may require some refactoring, I am not sure yet.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Good enough. Think on it.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Make a list of all the ideas we have had for improvements. We want<br>
> the code to get onto master.  <br>
> <br>
> The list should be converted to Trac tickets very soon. Then we can<br>
> decide which are critical for GSoC, which Chris or I will work on, and<br>
> which are part of your GSoC.<br>
<br>
Have these tickets been created?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Don't think so</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div>