On Mon, Mar 18, 2019 at 8:51 PM Joel Sherrill <j...@rtems.org> wrote:
> > > On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta <vaibhavgupt...@gmail.com> > wrote: > >> Okay, i read the header file, the functions defined in >> >> https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#id396 >> are still missing. >> . >> Can they be taken up for SoC project? >> > > Yep. As I tried to make clear on the other response, the implementation of > fenv.h > is target architecture dependent. > > + The Cygwin fenv.h is possibly x86 and/or x86_64. It can be moved as > appropriate > so the implementation is available to all users of that architecture. > > + Other architectures like ARM, PowerPC, SPARC, etc will need to be located > and ported to newlib or written. Just a quick search of the net turned up > this > directory from FreeBSD's github which has a number of architectures. > > This by itself is not going to be a full GSoC project but it is a good > first ticket to > tackle in a set of POSIX Compliance tasks. > So, for now, I have got 1 ticket for POSIX Compilance for SoC. As I went through documentation, following methods are also missing from math.h - fpclassify() - isfinite() - isgreater() - isgreaterequal() - isless() - islessequal() - islessgreater() - isnormal() - isunordered() - nexttowardf() - signbit() Can we add them up for GSoC? Thanks Vaibhav Gupta > > --joel > > >> On Mon, Mar 18, 2019 at 7:19 PM Vaibhav Gupta <vaibhavgupt...@gmail.com> >> wrote: >> >>> Ticket no #2971 https://devel.rtems.org/ticket/2971 >>> >>> The header file is present in newlib: >>> >>> $ find ./ -name \fenv.h >>> ./newlib-cygwin/winsup/cygwin/include/fenv.h >>> ./newlib-cygwin/newlib/libc/machine/spu/sys/fenv.h >>> ./newlib-cygwin/newlib/libc/machine/spu/include/fenv.h >>> ./newlib-cygwin/newlib/libc/machine/riscv/sys/fenv.h >>> ./newlib-cygwin/newlib/libc/machine/riscv/include/fenv.h >>> >>> ./newlib-cygwin/winsup/cygwin/include/fenv.h contains full >>> imlementation >>> as defined on http://pubs.opengroup.org/onlinepubs/9699919799/ >>> >>> On Mon, Mar 18, 2019 at 7:04 PM Vaibhav Gupta <vaibhavgupt...@gmail.com> >>> wrote: >>> >>>> Ticket no #3650 https://devel.rtems.org/ticket/3650 >>>> >>>> The header file is present in newlib: >>>> $ find ./ -name \ipc.h >>>> ./newlib-cygwin/winsup/cygwin/include/sys/ipc.h >>>> ./newlib-cygwin/winsup/cygwin/include/cygwin/ipc.h >>>> ./newlib-cygwin/newlib/libc/sys/phoenix/sys/ipc.h >>>> . >>>> and >>>> ./newlib-cygwin/winsup/cygwin/include/cygwin/ipc.h contains whole >>>> implementation. >>>> I guess, now we can enable the sys/ipc.h POSIX API Compliance Tests. >>>> >>>> On Sun, Mar 17, 2019 at 11:03 PM Vaibhav Gupta < >>>> vaibhavgupt...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill <j...@rtems.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta <vaibhavgupt...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> As mentioned by Dr Joel that high priority is to be given to >>>>>>> implementations missing in FACE GPP 3.0. >>>>>>> So, I have got FACE Technical Standard 3.0 pdf downloaded. And its >>>>>>> pretty easy to compare tickets now. >>>>>>> >>>>>> >>>>>> The FACE Technical Standard is a long and sleep inducing read. :) >>>>>> >>>>>> We have a POSIX Compliance document which tracks RTEMS vs various >>>>>> POSIX profiles. Many standards have POSIX profiles. SCA is for software >>>>>> radios. FACE TS was designed for cockpit software. Use the compliance >>>>>> document for ease: >>>>>> >>>>>> https://docs.rtems.org/branches/master/posix-compliance/index.html >>>>>> >>>>> Thanks, I guess this document contains the list of methods that are >>>>> already supported. I was comparing tickets with FACE to find which all are >>>>> still in need to be addressed. >>>>> >>>>> >>>>>> >>>>>> I track compliance against every standard I can find. >>>>>> >>>>> This is best for RTEMS >>>>> >>>>>> >>>>>> FYI I have supported the FACE Consortium for a number of years in >>>>>> various roles. >>>>>> >>>>>> >>>>>> >>>>>> . >>>>>>> And while exploring big picture I got many questions: >>>>>>> >>>>>>> 1 - It is mentioned in the ticket #2966, *"RTEMS POSIX Compliance >>>>>>> is achieved via a combination of methods and .h files in RTEMS and the >>>>>>> newlib C Library."* . >>>>>>> So, if a method or a header is present in Newlib C, it is not >>>>>>> required to be present in RTEMS library? But that would mean Newlib is >>>>>>> directly ported to RTEMS. >>>>>>> >>>>>> >>>>>> POSIX includes the entire C Library in its definition. Newlib is our >>>>>> C Library so if the method makes sense to be there, we add it to Newlib. >>>>>> >>>>>> In general, threading and synchronisation go in RTEMS. But ask for >>>>>> specific methods. It isn't always obvious. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> . >>>>>>> >>>>>>> *> I had an off-list talk with Vijay, he proved to be very helpful. >>>>>>> I asked him same question (question 1), I would like to conclude what we >>>>>>> discussed. * >>>>>>> >>>>>>> *> He told that "RTEMS uses its own version of Newlib C as it cannot >>>>>>> directly mirror original Newlib as, if methods change the way it works, >>>>>>> they can break RTEMS".* >>>>>>> >>>>>>> >>>>>>> *> But then my doubt was, if that's the case, why keep modified >>>>>>> headers of original Newlib under separate Newlib C folder in RTEMS? Why >>>>>>> not >>>>>>> directly include them in RTEMS library? (As I found >>>>>>> newlib-1d35a003f.tar.gz >>>>>>> in {RTEMS-ROOT}/rsb/rtems/sources/ )* >>>>>>> *.* >>>>>>> *> To which he replied, "RTEMS version of newlib is being used as a >>>>>>> libraby of RTEMS only and the posix functions are being linked to this >>>>>>> newlib"* >>>>>>> . >>>>>>> 2- So, My second doubt is that our target is to contribute to Newlib >>>>>>> C or RTEMS Library? Or we will add methods to Newlib C and link them to >>>>>>> RTEMS? >>>>>>> >>>>>>> Thanks >>>>>>> Vaibhav Gupta >>>>>>> >>>>>>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
