Gsoc 2018

Fri Mar 9 23:59:53 UTC 2018

See also Aditya's comments in "Re: devel Digest, Vol 76, Issue 23"

On Fri, Mar 9, 2018 at 4:16 PM, Joel Sherrill <joel at rtems.org> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel