Gsoc 2018

[Joel Sherrill]

I just pushed a pretty significant update to the POSIX Compliance guide.

+ preface has more guidance on where to look for missing methods to
implement
+ standards section attempts to describe each standard.
   If this section is insufficient, patches or suggestions are encouraged.
+ Added C11
+ Added FACE Technical Standard Edition 3.0 (four profiles)
+ Added Software Communications Architecture 2.2.2 (one profile)
+ Added Software Communications Architecture 4.1 (three profiles)

Having this updated should help you. If you want a couple of methods
that I think are on the easier side, look at the "utime" family. We
have utime() and utimes() but are missing futimens() and utimesnat().
Definitely the implementation goes in RTEMS (libc_support) and I
think they are fairly straightforward variants on the supported methods.

Adding the SPARC "fast" methods would be a good starting point
for familiarity with newlib.

Adding the fenv.h methods to newlib will be harder but rewarding
from a methods quantity perspective. I think this involves a little
header file surgery on the fenv.h there now and importing architecture
specific implementations from FreeBSD and NetBSD.

You will need to build tools with the RSB for every architecture you
add fenv.h support to. Because you have to know it compiles. :)

--joel

On Thu, Mar 8, 2018 at 2:20 PM, Joel Sherrill <joel at rtems.org> wrote:

>
>
> 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/20180309/fc09d4d3/attachment-0002.html>