On 15 January 2016 at 16:47, Gedare Bloom <ged...@rtems.org> wrote: > On Fri, Jan 15, 2016 at 5:57 AM, Darshit Shah <dar...@gmail.com> wrote: >> Hi Team, >> >> My name is Darshit Shah and I'd like to (potentially) be a part of the >> RTEMS project for GSoC 2016. I know that the organization applications >> open only next month, but I'm assuming that you will apply again this >> year and be selected as well. >> >> I'm sending this email to the devel mailing list since it mostly >> concerns development of RTEMS and may not be of wide interest to the >> audience of the users list. >> >> As of now, I have been through quite a bit of the Getting Started >> documentation available on the wiki, and have managed to set up a >> working environment for SPARC/SIS. The wiki says prospective students >> need to provide proof of setting up the environment. I've attached a >> patch file for the Hello World test program that I modified along with >> a screenshot after I ran it with `sparc-rtems4.11-run` instead of the >> gdb session as is shown on the wiki page. Please do let me know if I >> need to provide anything else. > Use 4.12 tools to build the master now. You don't need to resend the "proof".
I shall attempt this over the weekend. Should not be very different. > >> I've seen that the preferred method of sending patches to this mailing >> list is via git send-email which would send the patches inline. >> Currently my msmtp authentication is broken for some reason and hence >> I'm unable to use git send-email directly. And pasting a patch in >> Gmail is known to cause multiple issues. I'll fix my setup soon and be >> able to send future patches directly via the command line. >> > Attaching the patches are fine. That's perfect. I've seen certain mailing lists where they are extremely particular about patch submission, so I tend to try and stick to any provided documentation. > >> I'd also like to discuss about prospective open projects. I've been >> through the Open Projects page and found a few that I'd be interested >> in. Please do let me know if they're still available and if there's >> continued interest in seeing them fulfilled. I'm listing them in no >> particular order: >> >> 1. POSIX Compliance Test Suite: >> https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXComplianceTestSuite >> 2. Using Clang: >> https://devel.rtems.org/wiki/Developer/Projects/Open/UsingClang >> 3. Condition Variables: >> https://devel.rtems.org/wiki/Developer/Projects/Open/Condition_Variables >> 4. Nested Mutexes: >> https://devel.rtems.org/wiki/Developer/Projects/Open/StrictOrderMutex >> 5. Paravirtualization: >> https://devel.rtems.org/wiki/Developer/Projects/Open/Paravirtualization >> 6. Improve POSIX Compliance: >> https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXCompliance >> > Avoid 2 for now, until we replace autotools with waf the ability to > use clang is complicated by certain gcc-isms in our build and > configuration files. I did notice a little bit of it when I tried to compile it with clang earlier. The warning about usage of environment variables bit me a couple of times. > > 4 was more or less done, although not merged yet... You can consider > re-implementing Linux's approach to 4 if you like, but it may not be > particularly compelling. I could help clean up the existing patch set if required. Unless a reimplementation is indeed desired. > > 5 is iffy. I was actually a bit interested in this. Since it seemed to have the most potential where I get to "play" with multiple tools. I'd be interested in at least understanding the difficulties in this project. > > 1 and 6 are somewhat interesting coding projects. Yes. I thought so too. Though I would think 1 ought to be implemented before 6 to ensure correctness. Also, any thoughts on 3? Condition Variables was marked in bold to indicate an interesting project. > >> The above listed projects seem rather more interesting to me from the >> entire list and I would not mind working on any of them. I am open to >> other project suggestions as well. Since, I haven't played around with >> RTEMS enough as yet, I am unable to come up with a new idea myself. >> >> A little information about me: >> I'm a master's student in Computer Science at the Saarland University, >> Germany. My research interests are in Hard Real Time Systems, >> especially in providing hard bounds on WCET and Memory Requirements of >> algorithms being implemented. My Bachelor's Thesis was based on >> providing an analysis of the Read-Copy-Update Synchronization >> Primitive in a Hard Real Time context. Hence, RTEMS seems like a >> perfect match for me. >> > Given your background, you may also want to check out ticket #2510 on our > Trac. This is a rather interesting coincidence. Björn Brandenburg, the author of the paper mentioned in the ticket was my thesis advisor. He is also a faculty at my university. I was there when they went through this research. I'd gladly pick this up as a task. > >> >> -- >> Thanking You, >> Darshit Shah >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel -- Thanking You, Darshit Shah _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
