All right. I will get started with coverity right away On Fri, Feb 21, 2020 at 1:02 AM Gedare Bloom <ged...@rtems.org> wrote:
> On Thu, Feb 20, 2020 at 10:56 AM suyash singh <suyashsingh...@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 <ged...@rtems.org> wrote: > >> > >> On Thu, Feb 20, 2020 at 9:43 AM suyash singh <suyashsingh...@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 <ged...@rtems.org> > wrote: > >> >> > >> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill <j...@rtems.org> > wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard <jmill...@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@rtems.org > >> >> >> http://lists.rtems.org/mailman/listinfo/devel > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> devel mailing list > >> >> >> devel@rtems.org > >> >> >> http://lists.rtems.org/mailman/listinfo/devel > >> >> > > >> >> > _______________________________________________ > >> >> > devel mailing list > >> >> > devel@rtems.org > >> >> > http://lists.rtems.org/mailman/listinfo/devel > >> >> _______________________________________________ > >> >> devel mailing list > >> >> devel@rtems.org > >> >> http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
