Project query

Thu Feb 20 19:32:29 UTC 2020

On Thu, Feb 20, 2020 at 10:56 AM suyash singh <suyashsingh234 at gmail.com> wrote:
>
> I found this interesting project
> https://devel.rtems.org/ticket/3710
>
> There are no prerequisites given for this one
>
This one is a bit on the open-ended side. You should get started by
looking at our current status with Coverity, and triage a few bugs.
Convert "real bugs" from coverity scan into RTEMS tickets on Trac, or
do analysis to identify if a coverity vulnerability is actually a
false positive / not-a-bug. This will give you some level of
understanding about the Coverity workflow.

Beyond that, we will need to identify what, if any, patterns exist for
false positives, and whether we need to provide a more advanced
modeling file for Coverity. The content of our current modeling file
is pasted below. Some of these controls are only visible to
administrator accounts, so if the project moves forward you'd need
that permission. We'd deal with that if necessary.

There is also the possibility that clang-analyzer can be used. Jose
recently mentioned they got it to work with some "hacks" -- a good
project could be to make it working in a productive manner for our
open-source ecosystem.

I could see the two (coverity and clang-analyzer) being a good basis
for a GSoC that focuses on integration of static analysis tools in
RTEMS "devops"

Modeling file for RTEMS
---------------------------------------
//
// RTEMS-tools currently does not have anything to model for Coverity.
// Having a file makes them happy we have a fully configured project. :)
//

typedef unsigned int uint32_t;

void rtems_fatal_error_occurred(uint32_t the_error)
{
  __coverity_panic__();
}

#define rtems_interrupt_disable( _level ) \
  do { \
    _level = 0; \
  } while(0)

---------------------------------------

Gedare

> On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Thu, Feb 20, 2020 at 9:43 AM suyash singh <suyashsingh234 at gmail.com> wrote:
>> >
>> > So can I work on x86_64 BSP without hardware with simulator?
>> > https://devel.rtems.org/ticket/2898
>> >
>> > Also out of the prerequisites I only know C programming language but I am ready to learn everything else.
>> >
>> I think it will be too hard to work on a new BSP/port without the
>> assembly programming language experience in that architecture.
>>
>> I'd suggest you look for projects for which you possess all/most of
>> the prerequisites (when explicitly stated).
>>
>> Gedare
>>
>> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom <gedare at rtems.org> wrote:
>> >>
>> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill <joel at rtems.org> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard <jmillard at sprynet.com> wrote:
>> >> >>
>> >> >> Greetings:
>> >> >>
>> >> >> I took Joel’s week-long class in June.
>> >> >
>> >> >
>> >> > :) Thanks. Hope you enjoyed it.
>> >> >
>> >> >> 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.
>> >> >
>> >> >
>> >> > 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.
>> >> >
>> >> > 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.
>> >> >
>> >> >> 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.
>> >> >
>> >> >
>> >> > 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.
>> >> >
>> >> +1
>> >>
>> >> And so far few students to work on it, and it is a big area to work on.
>> >>
>> >> There is also an open project to improve legacy x86:
>> >> https://devel.rtems.org/ticket/2900
>> >>
>> >> >>
>> >> >> 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.
>> >> >
>> >> >
>> >> > For the most part, there isn't much priority. If you ask different people, you will likely get different answers.
>> >> >
>> >> >>
>> >> >> Suggestions welcome.
>> >> >>
>> >> >> John
>> >> >> —where there are tools, a will, and a will to build tools there is a way
>> >> >>
>> >> >> _________________________________
>> >> >>
>> >> >> devel mailing list
>> >> >> devel at rtems.org
>> >> >> http://lists.rtems.org/mailman/listinfo/devel
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> devel mailing list
>> >> >> devel at rtems.org
>> >> >> http://lists.rtems.org/mailman/listinfo/devel
>> >> >
>> >> > _______________________________________________
>> >> > devel mailing list
>> >> > devel at rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel
>> >> _______________________________________________
>> >> devel mailing list
>> >> devel at rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel