On Thu, Mar 8, 2018 at 1:27 PM, Salil Sirotia <salil.siro...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
