Participation in GSoC 2016

Fri Jan 15 16:44:49 UTC 2016

Considering your relationship with Dr. Brandenburg, you should
consider working on our SMP scheduling projects. Condition Variables
is part of that as well, and you may consider it. Sebastian Huber is
the best technical point-of-contact for the current state on both of
these, and he will (hopefully) chime in.

The paravirtualization project is stymied by the difficulty to
integrate the "glue code" needed to interface with hypervisors. The
remaining interesting bit of work is how to deal with missing
interrupts / time skips.

Gedare

Gedare

On Fri, Jan 15, 2016 at 11:04 AM, Darshit Shah <darnir at gmail.com> wrote:
> 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