On Wed, Jan 25, 2017 at 10:33 AM, Gedare Bloom <ged...@rtems.org> wrote:
> Hello Aditya Upadhyay, > > What is your goal for working on / contributing to RTEMS? > > POSIX Compliance is a reasonably good project to chip away at. Joel > should have a likely list of candidates to investigate. > > One of the issues with POSIX Compliance is determining what is feasible in the remaining methods. RTEMS is single process so any of the multiple process methods are not likely to be implementable in their fullest sense. We have managed to provide useful but incomplete support of some like getpid(). So that's the space in which the solution must be found. In spite of that, there are some methods missing that should be completely implementable. Also, I have been analysing RTEMS versus the POSIX profiles defined in the FACE Technical Standard which was designed for avionics systems. My starting list is against the FACE General Purpose Profile which is a subset of the full POSIX standard. There may be more missing which I am not listing. So here is what **WAS** missing versus the FACE General Purpose POSIX profile a few months ago. devctl.h posix_devctl fenv.h all 11 inttypes.h imaxdiv, wcstoimax & wcstoumax math.h 35. acoshl, acosl, asinl, atan2l, atanhl, coshl, erfcl, exp2l, expl, expm1l, fdiml, fmodl, frexpl, ilogbl, ldexpl, lgammal, llroundl, log10l, log1pl, log2l, logbl, logl, lroundl, modfl, nextafterl, nexttoward, nexttowardf, nexttowardl, powl, remainderl, remquol, scalblnl, scalbnl, sinhl, & tgammal spawn.h all 21 sys/mman.h mlock, mlockall, msync, munlock, munlockall, shm_open, & shm_unlink sys/select.h pselect sys/socket.h sockatmark unistd.h confstr Looking at that list, I have worked on posix_devctl() and believe that is complete minus the user manual. Gedare has worked on sys/mman.h and shm APIs. I would prioritize around inttypes.h, fenv, and unistd.h. The first two would have implementations in newlib, the C Library we use. That would still be a very valid part of a RTEMS GSoC Project. The implementation of confstr() I haven't thought about. The math.h methods may be able to be ported from FreeBSD or NetBSD to newlib. I am not sure of their existence in those OSes offhand though. Some research would be required. spawn.h requires multiple processes so we ignore it. The pselect method from sys/select.h should be provided by the new TCP/IP stack. Not sure about its status. > Update the TCP/IP Stack is basically done. There are however projects > within the networking area to look into. > > Agreed. I assume you refer to adding device drivers primarily. One task which shouldn't be enough to be a GSoC project is a USB bootable network application for the pc BSP which we can take around to various PCs and test drivers. > I'm not sure about the condition variables project. I think there is > still some small amount of work there. > > I suspect that is done. Condition variables are part of C11 and likely this was done for the special API project to speed up the TCP/IP stack. You should be using RTEMS version 4.12 for any new development effort. > Can you confirm that? > > Yes. Please confirm you are working on the master. --joel > Gedare > > On Wed, Jan 25, 2017 at 9:07 AM, aditya upadhyay <aadit0...@gmail.com> > wrote: > > Hello Developers, > > I am new in Open Source and willing to contribute.I have seen these > projects > > in " Embedded with RTEMS " page like Condition Variables, POSIX > > Compliance,Update the RTEMS TCP/IP Stack.I have build the tool chain for > > SPARC Instruction Simulator (SIS) BSP and modified the Hello World > command > > as described in the "GSOC Getting Started" page.Please point me to the > > document for the above projects so that i can start contributing. Please > > tell me the status of these projects and which of the above projects are > > still open and feasible for a beginner according to you. > > > > > > > > > > > > > > Thanks & Regards, > > Aditya Upadhyay > > Master Of Technology, > > Dept. of Computer Science & Engg., > > Indian Institute of Technology(ISM), Dhanbad > > Email id: aadit4...@gmail.com > > > > _______________________________________________ > > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel