Gsoc 2018

[Joel Sherrill]

On Thu, Mar 8, 2018 at 1:27 PM, Salil Sirotia <salil.sirotia at gmail.com>
wrote:

>
> Hello Developers,
>
> This is Salil Sirotia, Doing Masters from Indian Institute of
> Technology, Dhanbad. I want to participate in GSoC 2018 at your
> organization.
>

Hi.. I assume you have been talking to Aditya.   :)

>
>
> I have gone through the RTEMS Wiki page. I have set up the environment
> for SPARC and edited the application "Hello World". I am attaching the
> Screenshot of that Application Would you like to review the same.
>

Awesome. Please make a patch and send it as well using git format-patch.

Also add yourself to https://devel.rtems.org/wiki/GSoC/2018 where we
track what people are interested in doing.


>
>
>
> I am pretty good in C/C++, Python, Shell Scripting and worked on git and
> GDB.
>

The code in the POSIX Compliance is going to all be in C. Depending on the
method,
it will need to be in Newlib (libc/libm) or RTEMS itself.  Your Python
would come in
handy in updating the generation of the POSIX Compliance document.

The POSIX Compliance document is automatically generated from a spreadsheet
kept in the docs git repo. This is the easiest way to find methods missing.

https://git.rtems.org/rtems-docs/tree/posix-compliance is the source
directory
in the rtems-docs

https://docs.rtems.org/ has the generated version.


>
>
> I have gone through the open tickets and interested in POSIX
> Compliance Project: https://devel.rtems.org/ticket/2966. And i already
> have some idea about how to build new libraries and I think i might be
> able to do some good work in this project Would you like to point me some
> docs? I am really interested in this project.
>

This is a moving project. :)

Here are some odd things I know are desirable off the top of my head.

+ I would love to see fenv..h support added to newlib libm from FreeBSD.
+ I found an assembly version of SPARC memcpy which can be merged into
  newlib (for SPEED).  This is from whatever OpenSolaris is called now.
  There may be other str* or mem* methods worth bringing over.
+ Chris and I spotted a utime*() variant that is missing.  This would be
  implemented in RTEMS and it looked like the missing variant could
  easily be worked into the others.

Beyond that, I would work down the FACE General Purpose Profile based
on the POSIX Compliance Guide. That is supposed to reflect real avionics
embedded systems use.

I need to merge a new version of the tracking spreadsheet which includes
the recently released FACE Edition 3.0, POSIX 2003, the the Software
Communications Architecture profiles for 2.2.2 and 4.1. SCA was from
the OMG but is now from the Wireless Innovation Forum and it used
by software defined radios.

I hope this sounds interesting. POSIX is a huge standard and various
organizations have defined profiles (e.g. subsets) of it. The moving goal
is to support as much as technically possible and we use the profiles
to guide selection of methods. It is nice to say RTEMS has all the methods
in XYZ profile. :)


>
> Thanks & regards,
> Salil Sirotia,
>
>
> _______________________________________________
> 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/20180308/a5398a4e/attachment-0002.html>