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
