<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 17, 2016 at 9:52 AM, Darshit Shah <span dir="ltr"><<a href="mailto:darnir@gmail.com" target="_blank">darnir@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I agree. A SMP Scheduling based project would be a nice match for me.<br>
<br>
In fact, as suggested earlier, ticket #2510, about the implementing<br>
arbitrary processor affinities sounds rather interesting to me. I've<br>
been spending some time going through the paper once again, and soon<br>
I'll try and come up with an action plan on what could be a good GSoC<br>
project and further work beyond GSoC as well. Implementing the paper<br>
in its entirety may be too large for a single GSoC, but I should be<br>
able to split it into discrete smaller sections which can be<br>
completely implemented over a summer.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div><div style="font-size:12.8px">This would be a good project. I would add a few steps to simply implementing</div><div style="font-size:12.8px">it.  </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">+ Update the scheduling simulator since it is a lot easier to test using that.</div><div style="font-size:12.8px">   It is also easier to ensure you keep the same behavior.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">+ Propose criteria for knowing if the new algorithm is really better for </div><div style="font-size:12.8px">   RTEMS than the old one. Evaluating algorithms for RTEMS use involves</div><div style="font-size:12.8px">   big-O of the algorithm, data space requirements (and big-O of that), </div><div style="font-size:12.8px">   global knowledge required, and maybe other factors.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">+ Testing on scheduling simulator and in RTEMS testsuite to ensure</div><div style="font-size:12.8px">   it is functionally identical to the current algorithm.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">If the algorithm is functionally identical to the current one and superior</div><div style="font-size:12.8px">in execution time/data requirements, then replacing it is a no brainer.</div><div style="font-size:12.8px">If there are trade-offs on when one is better than the other in real life,</div><div style="font-size:12.8px">then we will all have to characterize those.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Ideally we end up replacing the current algorithm.  It is easier from an</div><div style="font-size:12.8px">RTEMS evolution when the replacement is clearly superior. :)</div><div class="" style="font-size:12.8px"></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
On 15 January 2016 at 17:44, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
> Considering your relationship with Dr. Brandenburg, you should<br>
> consider working on our SMP scheduling projects. Condition Variables<br>
> is part of that as well, and you may consider it. Sebastian Huber is<br>
> the best technical point-of-contact for the current state on both of<br>
> these, and he will (hopefully) chime in.<br>
><br>
> The paravirtualization project is stymied by the difficulty to<br>
> integrate the "glue code" needed to interface with hypervisors. The<br>
> remaining interesting bit of work is how to deal with missing<br>
> interrupts / time skips.<br>
><br>
> Gedare<br>
><br>
> Gedare<br>
><br>
> On Fri, Jan 15, 2016 at 11:04 AM, Darshit Shah <<a href="mailto:darnir@gmail.com">darnir@gmail.com</a>> wrote:<br>
>> On 15 January 2016 at 16:47, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>> On Fri, Jan 15, 2016 at 5:57 AM, Darshit Shah <<a href="mailto:darnir@gmail.com">darnir@gmail.com</a>> wrote:<br>
>>>> Hi Team,<br>
>>>><br>
>>>> My name is Darshit Shah and I'd like to (potentially) be a part of the<br>
>>>> RTEMS project for GSoC 2016. I know that the organization applications<br>
>>>> open only next month, but I'm assuming that you will apply again this<br>
>>>> year and be selected as well.<br>
>>>><br>
>>>> I'm sending this email to the devel mailing list since it mostly<br>
>>>> concerns development of RTEMS and may not be of wide interest to the<br>
>>>> audience of the users list.<br>
>>>><br>
>>>> As of now, I have been through quite a bit of the Getting Started<br>
>>>> documentation available on the wiki, and have managed to set up a<br>
>>>> working environment for SPARC/SIS. The wiki says prospective students<br>
>>>> need to provide proof of setting up the environment. I've attached a<br>
>>>> patch file for the Hello World test program that I modified along with<br>
>>>> a screenshot after I ran it with `sparc-rtems4.11-run` instead of the<br>
>>>> gdb session as is shown on the wiki page. Please do let me know if I<br>
>>>> need to provide anything else.<br>
>>> Use 4.12 tools to build the master now. You don't need to resend the "proof".<br>
>><br>
>> I shall attempt this over the weekend. Should not be very different.<br>
>>><br>
>>>> I've seen that the preferred method of sending patches to this mailing<br>
>>>> list is via git send-email which would send the patches inline.<br>
>>>> Currently my msmtp authentication is broken for some reason and hence<br>
>>>> I'm unable to use git send-email directly. And pasting a patch in<br>
>>>> Gmail is known to cause multiple issues. I'll fix my setup soon and be<br>
>>>> able to send future patches directly via the command line.<br>
>>>><br>
>>> Attaching the patches are fine.<br>
>> That's perfect. I've seen certain mailing lists where they are<br>
>> extremely particular about patch submission, so I tend to try and<br>
>> stick to any provided documentation.<br>
>>><br>
>>>> I'd also like to discuss about prospective open projects. I've been<br>
>>>> through the Open Projects page and found a few that I'd be interested<br>
>>>> in. Please do let me know if they're still available and if there's<br>
>>>> continued interest in seeing them fulfilled. I'm listing them in no<br>
>>>> particular order:<br>
>>>><br>
>>>> 1. POSIX Compliance Test Suite:<br>
>>>> <a href="https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXComplianceTestSuite" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXComplianceTestSuite</a><br>
>>>> 2. Using Clang: <a href="https://devel.rtems.org/wiki/Developer/Projects/Open/UsingClang" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/UsingClang</a><br>
>>>> 3. Condition Variables:<br>
>>>> <a href="https://devel.rtems.org/wiki/Developer/Projects/Open/Condition_Variables" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/Condition_Variables</a><br>
>>>> 4. Nested Mutexes:<br>
>>>> <a href="https://devel.rtems.org/wiki/Developer/Projects/Open/StrictOrderMutex" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/StrictOrderMutex</a><br>
>>>> 5. Paravirtualization:<br>
>>>> <a href="https://devel.rtems.org/wiki/Developer/Projects/Open/Paravirtualization" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/Paravirtualization</a><br>
>>>> 6. Improve POSIX Compliance:<br>
>>>> <a href="https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXCompliance" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXCompliance</a><br>
>>>><br>
>>> Avoid 2 for now, until we replace autotools with waf the ability to<br>
>>> use clang is complicated by certain gcc-isms in our build and<br>
>>> configuration files.<br>
>><br>
>> I did notice a little bit of it when I tried to compile it with clang<br>
>> earlier. The warning about usage of environment variables bit me a<br>
>> couple of times.<br>
>>><br>
>>> 4 was more or less done, although not merged yet... You can consider<br>
>>> re-implementing Linux's approach to 4 if you like, but it may not be<br>
>>> particularly compelling.<br>
>> I could help clean up the existing patch set if required. Unless a<br>
>> reimplementation is indeed desired.<br>
>><br>
>>><br>
>>> 5 is iffy.<br>
>> I was actually a bit interested in this. Since it seemed to have the<br>
>> most potential where I get to "play" with multiple tools. I'd be<br>
>> interested in at least understanding the difficulties in this project.<br>
>>><br>
>>> 1 and 6 are somewhat interesting coding projects.<br>
>> Yes. I thought so too. Though I would think 1 ought to be implemented<br>
>> before 6 to ensure correctness.<br>
>><br>
>> Also, any thoughts on 3? Condition Variables was marked in bold to<br>
>> indicate an interesting project.<br>
>>><br>
>>>> The above listed projects seem rather more interesting to me from the<br>
>>>> entire list and I would not mind working on any of them. I am open to<br>
>>>> other project suggestions as well. Since, I haven't played around with<br>
>>>> RTEMS enough as yet, I am unable to come up with a new idea myself.<br>
>>>><br>
>>>> A little information about me:<br>
>>>> I'm a master's student in Computer Science at the Saarland University,<br>
>>>> Germany. My research interests are in Hard Real Time Systems,<br>
>>>> especially in providing hard bounds on WCET and Memory Requirements of<br>
>>>> algorithms being implemented. My Bachelor's Thesis was based on<br>
>>>> providing an analysis of the Read-Copy-Update Synchronization<br>
>>>> Primitive in a Hard Real Time context. Hence, RTEMS seems like a<br>
>>>> perfect match for me.<br>
>>>><br>
>>> Given your background, you may also want to check out ticket #2510 on our Trac.<br>
>><br>
>> This is a rather interesting coincidence. Björn Brandenburg, the<br>
>> author of the paper mentioned in the ticket was my thesis advisor. He<br>
>> is also a faculty at my university. I was there when they went through<br>
>> this research. I'd gladly pick this up as a task.<br>
>>><br>
>>>><br>
>>>> --<br>
>>>> Thanking You,<br>
>>>> Darshit Shah<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> devel mailing list<br>
>>>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Thanking You,<br>
>> Darshit Shah<br>
<br>
<br>
<br>
--<br>
Thanking You,<br>
Darshit Shah<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></div></div></blockquote></div><br></div></div>