Participation in GSoC 2016

[Darshit Shah]

On 15 January 2016 at 16:47, Gedare Bloom <gedare at rtems.org> wrote:
> On Fri, Jan 15, 2016 at 5:57 AM, Darshit Shah <darnir at 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel



-- 
Thanking You,
Darshit Shah