On Mon, Mar 18, 2019 at 8:49 AM 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/ > This is for Cygwin -- not RTEMS. It is likely an implementation that would work for all x86 and x86_64 targets though. It should be moved to a more shared location in the source tree. The implementations under libc/machine are specific to processor architectures. In this case SPU (the Cell processor from the Playstation as I recall) and the RISC-V. RTEMS needs implementations for ARM, PowerPC, SPARC, x86, and MIPS as a good goal. I know this is confusing but newilb and RTEMS have code that is shared across all configurations and code that is specific to a small subset. > > 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
