Participation in GSoC 2016

Fri Jan 15 16:45:47 UTC 2016

On Fri, Jan 15, 2016 at 10: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

Gedare covered this.

>
> >> 5. Paravirtualization:
> >> https://devel.rtems.org/wiki/Developer/Projects/Open/Paravirtualization

I honestly don't know what we would encourage you to do off the top of my
head.

>
> >> 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.
>
>
1 and 6 are probably things I wrote up.

For (1), I am not thinking of implementing a new test suite as much
as leveraging existing code bases. For example, we do not test the
newlib C library. There is supposed to be a way to test it with the
glibc test suite but I have never done it and there is a list of known
failures.  Being able to run that would be a good thing and nice goal.
It could be a milestone on the path to (6)

For (6), there are some tickets for some missing methods. I have an
old list which I will update in the next week (I hope) which details
the methods missing per the Open Group FACE POSIX profiles.
You can download the PDF for FACE Technical Standard 2.1 at:

http://opengroup.org/face/information

My old notes has these pthread methods as missing versus
the FACE Safety Base profile. That is focused on single process
multi-threaded applications.

pthread_condattr_getclock
pthread_condattr_setclock
pthread_getcpuclockid
pthread_setschedprio
pthread_getconcurrency
pthread_setconcurrency

I also recall two missing stdint.h methods.  Beyond that, there are two
large categories of missing math methods in newlib to address. One
class is the complex long double and the other is the fenv.h
support.

POSIX 2013 added robust mutexes and those look to be interesting
for RTEMS.

Some of this goes in RTEMS proper and some would be enhancements
to newlib which would also benefit the Cygwin community.

(6) is a good GSoC project. It is a matter of what you are interested
in doing.

> Also, any thoughts on 3? Condition Variables was marked in bold to
> indicate an interesting project.
>

I think this is technically done. Sebastian implemented some low level
objects to improve performance of the new TCP/IP stack and GCC
libraries like C++ and OpenMP. Start a  separate email thread for
this. We may need to delete the task or rewrite it.

>
> >> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160115/9993ec93/attachment-0002.html>