<div dir="ltr">All right. I will get started with coverity right away</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 21, 2020 at 1:02 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 20, 2020 at 10:56 AM suyash singh <<a href="mailto:suyashsingh234@gmail.com" target="_blank">suyashsingh234@gmail.com</a>> wrote:<br>
><br>
> I found this interesting project<br>
> <a href="https://devel.rtems.org/ticket/3710" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3710</a><br>
><br>
> There are no prerequisites given for this one<br>
><br>
This one is a bit on the open-ended side. You should get started by<br>
looking at our current status with Coverity, and triage a few bugs.<br>
Convert "real bugs" from coverity scan into RTEMS tickets on Trac, or<br>
do analysis to identify if a coverity vulnerability is actually a<br>
false positive / not-a-bug. This will give you some level of<br>
understanding about the Coverity workflow.<br>
<br>
Beyond that, we will need to identify what, if any, patterns exist for<br>
false positives, and whether we need to provide a more advanced<br>
modeling file for Coverity. The content of our current modeling file<br>
is pasted below. Some of these controls are only visible to<br>
administrator accounts, so if the project moves forward you'd need<br>
that permission. We'd deal with that if necessary.<br>
<br>
There is also the possibility that clang-analyzer can be used. Jose<br>
recently mentioned they got it to work with some "hacks" -- a good<br>
project could be to make it working in a productive manner for our<br>
open-source ecosystem.<br>
<br>
I could see the two (coverity and clang-analyzer) being a good basis<br>
for a GSoC that focuses on integration of static analysis tools in<br>
RTEMS "devops"<br>
<br>
Modeling file for RTEMS<br>
---------------------------------------<br>
//<br>
// RTEMS-tools currently does not have anything to model for Coverity.<br>
// Having a file makes them happy we have a fully configured project. :)<br>
//<br>
<br>
typedef unsigned int uint32_t;<br>
<br>
void rtems_fatal_error_occurred(uint32_t the_error)<br>
{<br>
  __coverity_panic__();<br>
}<br>
<br>
#define rtems_interrupt_disable( _level ) \<br>
  do { \<br>
    _level = 0; \<br>
  } while(0)<br>
<br>
---------------------------------------<br>
<br>
Gedare<br>
<br>
> On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Thu, Feb 20, 2020 at 9:43 AM suyash singh <<a href="mailto:suyashsingh234@gmail.com" target="_blank">suyashsingh234@gmail.com</a>> wrote:<br>
>> ><br>
>> > So can I work on x86_64 BSP without hardware with simulator?<br>
>> > <a href="https://devel.rtems.org/ticket/2898" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2898</a><br>
>> ><br>
>> > Also out of the prerequisites I only know C programming language but I am ready to learn everything else.<br>
>> ><br>
>> I think it will be too hard to work on a new BSP/port without the<br>
>> assembly programming language experience in that architecture.<br>
>><br>
>> I'd suggest you look for projects for which you possess all/most of<br>
>> the prerequisites (when explicitly stated).<br>
>><br>
>> Gedare<br>
>><br>
>> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>> >><br>
>> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard <<a href="mailto:jmillard@sprynet.com" target="_blank">jmillard@sprynet.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Greetings:<br>
>> >> >><br>
>> >> >> I took Joel’s week-long class in June.<br>
>> >> ><br>
>> >> ><br>
>> >> > :) Thanks. Hope you enjoyed it.<br>
>> >> ><br>
>> >> >> I’m currently retired and looking for a project, but clearly not a GSoC guy. The default list of tickets is mostly old or currently assigned.<br>
>> >> ><br>
>> >> ><br>
>> >> > Currently assigned may not mean as much as you think. It is often done by someone to direct the ticket to who wrote the code. I know I often file tickets where I have looked into who is most likely to fix it and assign it to them.<br>
>> >> ><br>
>> >> > For example, I need to file a ticket for breakages building rtems-examples using waf. And when you build RTEMS using rtems6 tools, there are breakages because rtems5 is not replaced with rtems6 is still in some places. I reported both I think this week to devel.<br>
>> >> ><br>
>> >> >> The “open projects” page looks more relevant. I can buy hardware if somewhat reasonably priced. Having actual hardware would be somewhat preferred, even if qemu is amazing. I can do assembly (most familiar with Intel, but open to learning), low-level C down to the hardware, and have experience with OS level programming and drivers, serial and network transport, debuggers.<br>
>> >> ><br>
>> >> ><br>
>> >> > If that's the direction you want to go in, the x86_64 port and bsp are incomplete. There should be plenty of room to get things working. This would help ween us off of depending on legacy boot PCs.<br>
>> >> ><br>
>> >> +1<br>
>> >><br>
>> >> And so far few students to work on it, and it is a big area to work on.<br>
>> >><br>
>> >> There is also an open project to improve legacy x86:<br>
>> >> <a href="https://devel.rtems.org/ticket/2900" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2900</a><br>
>> >><br>
>> >> >><br>
>> >> >> Is there some priority on the projects? They are all equal, but some are more equal than others. I can guess the scope on some of them.<br>
>> >> ><br>
>> >> ><br>
>> >> > For the most part, there isn't much priority. If you ask different people, you will likely get different answers.<br>
>> >> ><br>
>> >> >><br>
>> >> >> Suggestions welcome.<br>
>> >> >><br>
>> >> >> John<br>
>> >> >> —where there are tools, a will, and a will to build tools there is a way<br>
>> >> >><br>
>> >> >> _________________________________<br>
>> >> >><br>
>> >> >> devel mailing list<br>
>> >> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> >> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> >> >><br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> devel mailing list<br>
>> >> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> >> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > devel mailing list<br>
>> >> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> >> _______________________________________________<br>
>> >> devel mailing list<br>
>> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>