Participation in GSoC 2016

Tue Jan 19 14:46:34 UTC 2016

On 17 January 2016 at 17:50, Joel Sherrill <joel.sherrill at gmail.com> wrote:
>
>
> On Sun, Jan 17, 2016 at 9:52 AM, Darshit Shah <darnir at gmail.com> wrote:
>>
>> I agree. A SMP Scheduling based project would be a nice match for me.
>>
>> In fact, as suggested earlier, ticket #2510, about the implementing
>> arbitrary processor affinities sounds rather interesting to me. I've
>> been spending some time going through the paper once again, and soon
>> I'll try and come up with an action plan on what could be a good GSoC
>> project and further work beyond GSoC as well. Implementing the paper
>> in its entirety may be too large for a single GSoC, but I should be
>> able to split it into discrete smaller sections which can be
>> completely implemented over a summer.
>
>
> This would be a good project. I would add a few steps to simply implementing
> it.
>
> + Update the scheduling simulator since it is a lot easier to test using
> that.
>    It is also easier to ensure you keep the same behavior.

This sounds like a good idea. Can someone kindly point me to the right
set of resources / codebase for looking at this?
Also, some smaller bug fixes / features that I could work on to get
used to the code base would be excellent.

>
> + Propose criteria for knowing if the new algorithm is really better for
>    RTEMS than the old one. Evaluating algorithms for RTEMS use involves
>    big-O of the algorithm, data space requirements (and big-O of that),
>    global knowledge required, and maybe other factors.
This is an important step. I will look into an analysis of both, the
existing and the new algorithms and provide updates on what I find.
Irrespective of GSoC, this sounds like an interesting project to embark upon.
>
> + Testing on scheduling simulator and in RTEMS testsuite to ensure
>    it is functionally identical to the current algorithm.
I'm guessing this would be done after we implement the algorithm,
right? Or did I miss something?
We would atleast have to implement it in the simulator.
>
> If the algorithm is functionally identical to the current one and superior
> in execution time/data requirements, then replacing it is a no brainer.
> If there are trade-offs on when one is better than the other in real life,
> then we will all have to characterize those.
>
> Ideally we end up replacing the current algorithm.  It is easier from an
> RTEMS evolution when the replacement is clearly superior. :)
>

Now, I'm only looking for smaller tasks I can work on to get used to
the codebase and toolchain. So any pointers there will be greatly
appreciated.
As asked earlier, I've built the tool set for 4.12 as well.

> --joel
>
>
>>
>> On 15 January 2016 at 17:44, Gedare Bloom <gedare at rtems.org> wrote:
>> > 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
>>
>>
>>
>> --
>> Thanking You,
>> Darshit Shah
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>

-- 
Thanking You,
Darshit Shah