On Tue, Mar 19, 2019 at 12:39 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Mon, Mar 18, 2019 at 12:01 PM Vaibhav Gupta <vaibhavgupt...@gmail.com> > wrote: > >> Under "Tasks without Tickets": >> https://devel.rtems.org/ticket/2966#TasksWithoutTickets >> . >> . >> >> Newlib also has some known issues: >> >> - math.h missing some methods >> - long double complex methods. These could come from FreeBSD but >> we need to be careful since there may be architecture specific >> implementations. https://wiki.freebsd.org/Numerics >> >> Yep. Same guidelines as fenv.h except for a warning that some > architectures > do not have long double support so double is long double. > > I thought this had a ticket but apparently it is listed as one needing a > ticket filed. > Yes this one is higher priority than the lack of a ticket indicates. It > needs a ticket > filed. If it has the right keywords, it will show up in the master POSIX > Compliance > ticket. > I had a talk with Aditya and he mentioned that most of the work for long complex is already done by him, so not much work is left. > > Good news, these appear to be included in FreeBSD now in the same directory > I pointed you to for the fenv.h. So once you get the hang of adding things > to > newlib, this should be a very successful project. > > Experience says these tasks can be easy, hard, or need to be abandoned > since > the method won't work in a single process system like RTEMS so pick at > least 5 > to attempt. fenv.h and the long double are a good start. > > What's left against FACE 3.0 General Purpose Profile? > > NOTE: There is an approved change request against FACE 3.0 to make ' > support for multiple processes optional. Any method listed in the FACE > Technical Standard Edition 3.0, in Appendix A.1 as POSIX_MULTI_PROCESS > is now optional. > > > https://ticketing.facesoftware.org/face_user_bug_view.php?id=330&tab=submitter > > So FACE CR330 eliminated the requirement to support methods which RTEMS > cannot support. With attention to the remaining APIs that are missing, > RTEMS > can meet FACE General Purpose. > > Sorry for the side discussion of that FACE CR. But it was filed so > operating > systems like RTEMS could meet the General Purpose Profile. > > I hope that made sense. > It did, Let me summarize what all things are left on FACE GPP -- fenv.h -- math functions: - fpclassify() - isfinite() - isgreater() - isgreaterequal() - isless() - islessequal() - islessgreater() - isnormal() - isunordered() - nexttowardf() - signbit() -- spawn function: - posix_spawn() - posix_spawn_file_actions_addclose() - posix_spawn_file_actions_adddup2() - posix_spawn_file_actions_addopen() - posix_spawn_file_actions_destroy() - posix_spawn_file_actions_init() - posix_spawnattr_destroy() - posix_spawnattr_getflags() - posix_spawnattr_getpgroup() - posix_spawnattr_getschedparam() - posix_spawnattr_getschedpolicy() - posix_spawnattr_getsigdefault() - posix_spawnattr_getsigmask() - posix_spawnattr_init() - posix_spawnattr_setflags() - posix_spawnattr_setpgroup() - posix_spawnattr_setschedparam() - posix_spawnattr_setschedpolicy() - posix_spawnattr_setsigdefault() - posix_spawnattr_setsigmask() - posix_spawnp() -- pselect() from <sys/select.h> -- sockatmark() from <sys/socket.h> -- confstr() from <unistd.h> These Functions are not supported from FACE GPP. And I guess they make a good project for GSoC Moreover, Aditya gave me an init.c file, and I am trying to run it inside testsuites, as he said, it will give me more brief Idea for SoC Projects. Thanks Vaibhav Gupta > > --joel > > > > >> . >> can we add missing methods for SoC for POSIX Compilance? >> >> On Mon, Mar 18, 2019 at 8:58 PM Vaibhav Gupta <vaibhavgupt...@gmail.com> >> wrote: >> >>> >>> >>> 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
