GSoC: Matt Joyce Introduction

[Joel Sherrill]

On Wed, Mar 17, 2021 at 10:50 AM Gedare Bloom <gedare at rtems.org> wrote:

> Hi Matt,
>
> On Wed, Mar 17, 2021 at 6:18 AM Matthew Joyce <mfjoyce2004 at gmail.com>
> wrote:
> >
> > Hello RTEMS Community!
> >
> > My name is Matt, I’m a former US Army infantry officer, now back in
> school pursuing a second bachelor’s in Computer Science at Oregon State
> University.
> >
> > I am new to open source, but I am just completing my second (elective)
> operating systems course and have a class in x86 assembly language under my
> belt. I’m starting my first class in embedded programming at the end of the
> month. (I’m excited!)
> >
> Welcome! That sounds like a good baseline to start with RTEMS from.
>

+1 RTEMS as GSoC should be a good pairing with that class.

>
> >
> >
> > Based on the long-term participation of previous years’ GSoC students, I
> see that this community is committed to stewarding the project into the
> future. And I see that the work you do is literally out there among the
> stars. That is what I’d call a legacy! I know that I could learn so much
> from the community, and hopefully, with a lot of sweat, contribute
> something as well.
> >
> > One project in which I’m interested is #4328: “New APIs Added to POSIX
> Standard (2021)”. I would be grateful if someone could help me understand
> the current state of this effort and where it fits into the greater “POSIX
> Compliance” effort (#2966). I notice in the “Small Projects” section there
> is a task to flesh out the RTEMS POSIX User’s Guide. I thought that this
> might be a good way for me to build up my understanding of RTEMS, prepare
> me to better work on 4328, and add something along the way. Is that
> something that would be helpful?
> >
>
> Joel should be able to provide guidance on both fronts. Improving the
> documentation is always helpful. The POSIX code improvements are often
> a good, incremental coding activity.
>

As the 2021 in the title implies, this is quite new. The POSIX working group
just announced the draft of what should be coming this month. The first
step is to go through the document linked and see what methods are added
(or deleted). It has change bars and I think you can just search for "+" to
find text additions.

(1) Make a master list of what is added. A Google Sheet is nice for this.
(2) With help, we figure out what already is in RTEMS and our C Library.

Those two provide a baseline of what could be picked from as new methods
to add. For that subset, we will work together to see what you could port
from FreeBSD, NetBSD, or somewhere else with a permissive license;
what cannot be implemented on RTEMS, and what has to be written from
scratch. Some of the possible will be the GSoC project you propose.

Gedare is right about it being incremental. There are usually related
sets of methods and you add a set, test it, put the patch(es) out for
review, repeat. Based on Eshan's experience last year, you can easily
have a handful of method sets at different stages. You will get feedback
and have to make updates. Some patches go to the newlib C Library
we use and those sometimes get comments we just don't make because
we usually don't catch impact on non-RTEMS targets.

Anyway, this is a good project and I'm the primary mentor for these
POSIX tasks..

--joel


>
> >
> >
> > It’s nice to “meet” you all and I look forward to hearing back from you!
> >
>
> Great. One thing you might consider is to use plain-text mode instead
> of HTML/rich-text editor. It will make your emails easier to reply to
> in threaded context.
>
> Gedare
>
> >
> >
> > Sincerely,
> >
> > Matt
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20210318/b094fa90/attachment-0001.html>