Project query

[suyash singh]

All right. I will get started with coverity right away

On Fri, Feb 21, 2020 at 1:02 AM Gedare Bloom <gedare at rtems.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200221/7cebf661/attachment-0001.html>