Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

On Mon, Mar 18, 2019 at 4:40 AM Gedare Bloom  wrote:

> On Sun, Mar 17, 2019 at 2:24 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Sun, Mar 17, 2019, 12:45 PM Vaibhav Gupta 
> wrote:
> >>
> >> I did cloned RTEM source, newlib and rtems-libbsd.
> >> Kept them in same folder so as to get easy with 'grep' and 'find'.
> >>
> >> $ ls
> >> newlib-cygwin  rtems  rtems-libbsd
> >>
> >> $ grep -r grantpt ./
> >> ./newlib-cygwin/winsup/doc/posix.xml:grantpt
> >> ./newlib-cygwin/winsup/doc/posix.xml:return -1 and set errno to
> ENOSYS.  grantpt and
> >> ./newlib-cygwin/winsup/cygwin/tty.cc:grantpt (int fd)
> >> ./newlib-cygwin/winsup/cygwin/libc/bsdlib.cc:  grantpt (master);
> >> ./newlib-cygwin/winsup/cygwin/common.din:grantpt NOSIGFE
> >> ./newlib-cygwin/winsup/cygwin/include/cygwin/stdlib.h:int grantpt (int);
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:*
> cygwin.din: srandom, ptsname, grantpt, unlockpt - new exports.
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:
> (grantpt): new
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2001:*
> tty.cc (grantpt): Fix definition.
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2011:*
> tty.cc (grantpt): Check for valid fd.
> >> ./newlib-cygwin/newlib/ChangeLog-2015:* libc/include/stdlib.h: add
> ptsname, grantpt, unlockpt to cygwin
> >> ./rtems/testsuites/psxtests/Makefile.am:## lib_a_SOURCES +=
> psxhdrs/stdlib/grantpt.c  See ticket #3645
> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c: *  @brief
> grantpt() API Conformance Test
> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c:return_value =
> grantpt(fildes);
> >> .
> >> .
> >> As I analyzed the output, I find no file that contains implementation
> of 'grantpt()', means ticket #3645(https://devel.rtems.org/ticket/3645)
> still needs to be addressed.
> >> But then how this method is used in rtems testsuites?. (refer last two
> lines of output for grep command).
> >> .
> >> Am I doing something wrong? or I am missing something.
> >
> >
> > You haven't done anything wrong.
> >
> > The grantpt() method is in a winsup subdirectory which indicates it is a
> Cygwin specific implementation.
> >
> > The psxhdrs test just checks that the prototype us right in the header
> file.
> >
> > All said, I don't know if grantpt makes sense on RTEMS or not. That's a
> different discussion.
> >
> >>
> >> Thanks
> >> Vaibhav Gupta
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Mar 8, 2019 at 5:31 AM Joel Sherrill  wrote:
> >>>
> >>> I'm about to head home so not going to dig into each of those but I
> >>> will point out for GSoC, we need to get you where you can answer
> >>> these questions yourself.
> >>>
> >>> 1) clone the newlib (sourceware.org/newlib) source, RTEMS source, and
> >>> rtems-libbsd source. rtems-libbsd is the source for networking
> APIs.
> >>> 2) use "grep -r" (recursive grep) and find (ex: find . -name "XXX") to
> help you
> >>> find implementations.
> >>>
> >>> For #3676, RTEMS supports aio but aio.h is one of only a handful of
> POSIX
> >>> .h files in RTEMS and not in newlib. That's why the Google Code-In
> student
> >>> couldn't find it in newlib. Just scanning the cpukit/include, I see 3
> POSIX .h
> >>> files which could be moved to newlib. This is worth discussing on
> devel@
> >>>
> >>> For the rest, I think they are still open to be implemented. Now
> whether the
> >>> method makes sense or not on RTEMS or requires more infrastructure than
> >>> a simple method to be added is something to determine on a case by case
> >>> basis.
> >>>
> >>> --joel
> >>>
> >>> On Thu, Mar 7, 2019 at 5:51 PM Vaibhav Gupta 
> wrote:
> 
>  It will be very helpful to know the current status of the following
> tickets, and if I can choose sub-tasks from them, for GSoC project.
> 
>  .
>  #3676 - Add support for aio.h
>  .
>  #3642 - Add iswalnum(), iswalpha() ... (and 18 others) to 
> header
>  .
>  #3371 - Add dirfd() and fdopendir() methods in dirent.h
>  .
>  #3656 - Function prototypes for posix_fadvise() and posix_fallocate()
> missing in  header file
>  .
>  #3652- Add support for sys/resource.h method - getpriority
>  .
>  #3653 - Add support for sys/resource.h method - getrlimit
>  .
>  #3654 - Add support for sys/resource.h method - setpriority
>  .
>  #3655 - Add support for sys/resource.h method - setrlimit
>  .
>  #3644 - Add support for stdlib.h method - getsubopt
>  .
>  #3645 - Add support for stdlib.h method - grantpt
>  .
>  #3646 - Add support for stdlib.h method - posix_openpt
>  .
>  #3647 - Add support for stdlib.h method - ptsname
>  .
>  #3648 - Add support for stdlib.h method - unlockpt
>  .
>  #3643 - Add support for uchar.h header
>  .
>  #3633 - add getdelim() and getline() to stdio.h
> 
> 
>  Vaibhav Gupta
> >

Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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 
wrote:

>
>
> On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta 
>> 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

Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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 
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 
> wrote:
>
>>
>>
>> On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta 
>>> 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

Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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?

On Mon, Mar 18, 2019 at 7:19 PM Vaibhav Gupta 
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 
> 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 
>> wrote:
>>
>>>
>>>
>>> On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill  wrote:
>>>


 On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta 
 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

Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

On Mon, Mar 18, 2019 at 4:40 AM Gedare Bloom  wrote:

> On Sun, Mar 17, 2019 at 2:24 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Sun, Mar 17, 2019, 12:45 PM Vaibhav Gupta 
> wrote:
> >>
> >> I did cloned RTEM source, newlib and rtems-libbsd.
> >> Kept them in same folder so as to get easy with 'grep' and 'find'.
> >>
> >> $ ls
> >> newlib-cygwin  rtems  rtems-libbsd
> >>
> >> $ grep -r grantpt ./
> >> ./newlib-cygwin/winsup/doc/posix.xml:grantpt
> >> ./newlib-cygwin/winsup/doc/posix.xml:return -1 and set errno to
> ENOSYS.  grantpt and
> >> ./newlib-cygwin/winsup/cygwin/tty.cc:grantpt (int fd)
> >> ./newlib-cygwin/winsup/cygwin/libc/bsdlib.cc:  grantpt (master);
> >> ./newlib-cygwin/winsup/cygwin/common.din:grantpt NOSIGFE
> >> ./newlib-cygwin/winsup/cygwin/include/cygwin/stdlib.h:int grantpt (int);
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:*
> cygwin.din: srandom, ptsname, grantpt, unlockpt - new exports.
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:
> (grantpt): new
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2001:*
> tty.cc (grantpt): Fix definition.
> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2011:*
> tty.cc (grantpt): Check for valid fd.
> >> ./newlib-cygwin/newlib/ChangeLog-2015:* libc/include/stdlib.h: add
> ptsname, grantpt, unlockpt to cygwin
> >> ./rtems/testsuites/psxtests/Makefile.am:## lib_a_SOURCES +=
> psxhdrs/stdlib/grantpt.c  See ticket #3645
> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c: *  @brief
> grantpt() API Conformance Test
> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c:return_value =
> grantpt(fildes);
> >> .
> >> .
> >> As I analyzed the output, I find no file that contains implementation
> of 'grantpt()', means ticket #3645(https://devel.rtems.org/ticket/3645)
> still needs to be addressed.
> >> But then how this method is used in rtems testsuites?. (refer last two
> lines of output for grep command).
> >> .
> >> Am I doing something wrong? or I am missing something.
> >
> >
> > You haven't done anything wrong.
> >
> > The grantpt() method is in a winsup subdirectory which indicates it is a
> Cygwin specific implementation.
> >
> > The psxhdrs test just checks that the prototype us right in the header
> file.
> >
> > All said, I don't know if grantpt makes sense on RTEMS or not. That's a
> different discussion.
> >
> >>
> >> Thanks
> >> Vaibhav Gupta
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Mar 8, 2019 at 5:31 AM Joel Sherrill  wrote:
> >>>
> >>> I'm about to head home so not going to dig into each of those but I
> >>> will point out for GSoC, we need to get you where you can answer
> >>> these questions yourself.
> >>>
> >>> 1) clone the newlib (sourceware.org/newlib) source, RTEMS source, and
> >>> rtems-libbsd source. rtems-libbsd is the source for networking
> APIs.
> >>> 2) use "grep -r" (recursive grep) and find (ex: find . -name "XXX") to
> help you
> >>> find implementations.
> >>>
> >>> For #3676, RTEMS supports aio but aio.h is one of only a handful of
> POSIX
> >>> .h files in RTEMS and not in newlib. That's why the Google Code-In
> student
> >>> couldn't find it in newlib. Just scanning the cpukit/include, I see 3
> POSIX .h
> >>> files which could be moved to newlib. This is worth discussing on
> devel@
> >>>
> >>> For the rest, I think they are still open to be implemented. Now
> whether the
> >>> method makes sense or not on RTEMS or requires more infrastructure than
> >>> a simple method to be added is something to determine on a case by case
> >>> basis.
> >>>
> >>> --joel
> >>>
> >>> On Thu, Mar 7, 2019 at 5:51 PM Vaibhav Gupta 
> wrote:
> 
>  It will be very helpful to know the current status of the following
> tickets, and if I can choose sub-tasks from them, for GSoC project.
> 
>  .
>  #3676 - Add support for aio.h
>  .
>  #3642 - Add iswalnum(), iswalpha() ... (and 18 others) to 
> header
>  .
>  #3371 - Add dirfd() and fdopendir() methods in dirent.h
>  .
>  #3656 - Function prototypes for posix_fadvise() and posix_fallocate()
> missing in  header file
>  .
>  #3652- Add support for sys/resource.h method - getpriority
>  .
>  #3653 - Add support for sys/resource.h method - getrlimit
>  .
>  #3654 - Add support for sys/resource.h method - setpriority
>  .
>  #3655 - Add support for sys/resource.h method - setrlimit
>  .
>  #3644 - Add support for stdlib.h method - getsubopt
>  .
>  #3645 - Add support for stdlib.h method - grantpt
>  .
>  #3646 - Add support for stdlib.h method - posix_openpt
>  .
>  #3647 - Add support for stdlib.h method - ptsname
>  .
>  #3648 - Add support for stdlib.h method - unlockpt
>  .
>  #3643 - Add support for uchar.h header
>  .
>  #3633 - add getdelim() and getline() to stdio.h
> 
> 
>  Vaibhav Gupta
> >

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

On Mon, Mar 18, 2019 at 8:49 AM Vaibhav Gupta 
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 
> 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 
>> wrote:
>>
>>>
>>>
>>> On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill  wrote:
>>>


 On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta 
 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

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta 
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.

--joel


> On Mon, Mar 18, 2019 at 7:19 PM Vaibhav Gupta 
> 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 
>> 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 
>>> wrote:
>>>


 On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill  wrote:

>
>
> On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta 
> 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

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

On Mon, Mar 18, 2019 at 10:07 AM Vaibhav Gupta 
wrote:

>
>
> On Mon, Mar 18, 2019 at 4:40 AM Gedare Bloom  wrote:
>
>> On Sun, Mar 17, 2019 at 2:24 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Sun, Mar 17, 2019, 12:45 PM Vaibhav Gupta 
>> wrote:
>> >>
>> >> I did cloned RTEM source, newlib and rtems-libbsd.
>> >> Kept them in same folder so as to get easy with 'grep' and 'find'.
>> >>
>> >> $ ls
>> >> newlib-cygwin  rtems  rtems-libbsd
>> >>
>> >> $ grep -r grantpt ./
>> >> ./newlib-cygwin/winsup/doc/posix.xml:grantpt
>> >> ./newlib-cygwin/winsup/doc/posix.xml:return -1 and set errno to
>> ENOSYS.  grantpt and
>> >> ./newlib-cygwin/winsup/cygwin/tty.cc:grantpt (int fd)
>> >> ./newlib-cygwin/winsup/cygwin/libc/bsdlib.cc:  grantpt (master);
>> >> ./newlib-cygwin/winsup/cygwin/common.din:grantpt NOSIGFE
>> >> ./newlib-cygwin/winsup/cygwin/include/cygwin/stdlib.h:int grantpt
>> (int);
>> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:*
>> cygwin.din: srandom, ptsname, grantpt, unlockpt - new exports.
>> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-1997:
>> (grantpt): new
>> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2001:*
>> tty.cc (grantpt): Fix definition.
>> >> ./newlib-cygwin/winsup/CVSChangeLogs.old/cygwin/ChangeLog-2011:*
>> tty.cc (grantpt): Check for valid fd.
>> >> ./newlib-cygwin/newlib/ChangeLog-2015:* libc/include/stdlib.h: add
>> ptsname, grantpt, unlockpt to cygwin
>> >> ./rtems/testsuites/psxtests/Makefile.am:## lib_a_SOURCES +=
>> psxhdrs/stdlib/grantpt.c  See ticket #3645
>> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c: *  @brief
>> grantpt() API Conformance Test
>> >> ./rtems/testsuites/psxtests/psxhdrs/stdlib/grantpt.c:return_value
>> = grantpt(fildes);
>> >> .
>> >> .
>> >> As I analyzed the output, I find no file that contains implementation
>> of 'grantpt()', means ticket #3645(https://devel.rtems.org/ticket/3645)
>> still needs to be addressed.
>> >> But then how this method is used in rtems testsuites?. (refer last two
>> lines of output for grep command).
>> >> .
>> >> Am I doing something wrong? or I am missing something.
>> >
>> >
>> > You haven't done anything wrong.
>> >
>> > The grantpt() method is in a winsup subdirectory which indicates it is
>> a Cygwin specific implementation.
>> >
>> > The psxhdrs test just checks that the prototype us right in the header
>> file.
>> >
>> > All said, I don't know if grantpt makes sense on RTEMS or not. That's a
>> different discussion.
>> >
>> >>
>> >> Thanks
>> >> Vaibhav Gupta
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Mar 8, 2019 at 5:31 AM Joel Sherrill  wrote:
>> >>>
>> >>> I'm about to head home so not going to dig into each of those but I
>> >>> will point out for GSoC, we need to get you where you can answer
>> >>> these questions yourself.
>> >>>
>> >>> 1) clone the newlib (sourceware.org/newlib) source, RTEMS source, and
>> >>> rtems-libbsd source. rtems-libbsd is the source for networking
>> APIs.
>> >>> 2) use "grep -r" (recursive grep) and find (ex: find . -name "XXX")
>> to help you
>> >>> find implementations.
>> >>>
>> >>> For #3676, RTEMS supports aio but aio.h is one of only a handful of
>> POSIX
>> >>> .h files in RTEMS and not in newlib. That's why the Google Code-In
>> student
>> >>> couldn't find it in newlib. Just scanning the cpukit/include, I see 3
>> POSIX .h
>> >>> files which could be moved to newlib. This is worth discussing on
>> devel@
>> >>>
>> >>> For the rest, I think they are still open to be implemented. Now
>> whether the
>> >>> method makes sense or not on RTEMS or requires more infrastructure
>> than
>> >>> a simple method to be added is something to determine on a case by
>> case
>> >>> basis.
>> >>>
>> >>> --joel
>> >>>
>> >>> On Thu, Mar 7, 2019 at 5:51 PM Vaibhav Gupta <
>> vaibhavgupt...@gmail.com> wrote:
>> 
>>  It will be very helpful to know the current status of the following
>> tickets, and if I can choose sub-tasks from them, for GSoC project.
>> 
>>  .
>>  #3676 - Add support for aio.h
>>  .
>>  #3642 - Add iswalnum(), iswalpha() ... (and 18 others) to 
>> header
>>  .
>>  #3371 - Add dirfd() and fdopendir() methods in dirent.h
>>  .
>>  #3656 - Function prototypes for posix_fadvise() and
>> posix_fallocate() missing in  header file
>>  .
>>  #3652- Add support for sys/resource.h method - getpriority
>>  .
>>  #3653 - Add support for sys/resource.h method - getrlimit
>>  .
>>  #3654 - Add support for sys/resource.h method - setpriority
>>  .
>>  #3655 - Add support for sys/resource.h method - setrlimit
>>  .
>>  #3644 - Add support for stdlib.h method - getsubopt
>>  .
>>  #3645 - Add support for stdlib.h method - grantpt
>>  .
>>  #3646 - Add support for stdlib.h method - posix_openpt
>>  .
>>  #3647 - Add support for stdlib.h method 

Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

On Mon, Mar 18, 2019 at 8:51 PM Joel Sherrill  wrote:

>
>
> On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta 
> 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 
>> 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 
>>> 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  wrote:
>
>>
>>
>> On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta 
>> 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 o

Re: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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

.
can we add missing methods for SoC for POSIX Compilance?

On Mon, Mar 18, 2019 at 8:58 PM Vaibhav Gupta 
wrote:

>
>
> On Mon, Mar 18, 2019 at 8:51 PM Joel Sherrill  wrote:
>
>>
>>
>> On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta 
>> 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 
>>> 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 
 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  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
 req

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

On Mon, Mar 18, 2019 at 10:29 AM Vaibhav Gupta 
wrote:

>
>
> On Mon, Mar 18, 2019 at 8:51 PM Joel Sherrill  wrote:
>
>>
>>
>> On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta 
>> 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?
>

This appears to be the set defined in fenv.h so yes this is one of the
tasks under the
POSIX Compliance umbrella. Remember this one will involve providing
implementations
for multiple architectures and test code.

--joel

>
> Thanks
> Vaibhav Gupta
>
>>
>> --joel
>>
>>
>>> On Mon, Mar 18, 2019 at 7:19 PM Vaibhav Gupta 
>>> 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 
 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  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 

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

On Mon, Mar 18, 2019 at 12:01 PM Vaibhav Gupta 
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.

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.

--joel




> .
> can we add missing methods for SoC for POSIX Compilance?
>
> On Mon, Mar 18, 2019 at 8:58 PM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Mon, Mar 18, 2019 at 8:51 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta 
>>> 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 
 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 <
>> vaibhav

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

Hi Christian,


On Sun, 17 Mar 2019 at 14:30, Christian Mauderer  wrote:

> Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer  > > wrote:
> >
> > Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > > Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > > > Hello,
> > > >
> > > > I am trying to `./waf install` the libbsd but getting some
> > error,
> > > need help
> > > > with that. The commands used and the errors are given below
> ...
> > > >
> > > > configured using: `./waf configure
> > --buildset=buildset/default.ini
> > > > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> > > >
> > > > configure was successful.
> > > >
> > > > then : `./waf install`
> > > >
> > > > Error ...
> > > > 
> > > > Build failed
> > > >  -> task in 'lex__nsyy' failed with exit status 1 (run with
> > -v to
> > > > display more information)
> > > >  -> task in 'yacc__nsyy' failed with exit status 1 (run with
> > -v to
> > > > display more information)
> > > >  -> task in 'lex_pcap' failed with exit status 1 (run with
> -v to
> > > display
> > > > more information)
> > > >  -> task in 'yacc_pcap' failed with exit status 1 (run with
> > -v to
> > > > display more information)
> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
> > to display
> > > > more information)
> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
> > to display
> > > > more information)
> > > >  -> task in 'yacc_pfctly' failed with exit status 1 (run
> > with -v to
> > > > display more information)
> > > >
> > > > 
> > > >
> > > > Thanks
> > > > --vijay
> > > >
> > >
> > > Hello Vijay,
> > >
> > > did you try to build before the install? I don't see the call.
> > > Normally it's
> > >
> > >   waf configure ...
> > >   waf
> > >   waf install
> > >
> > > If you did that: It seems that some of the lex / yacc files
> > should be
> > > regenerated. Did you enable --enable-auto-regen somewhen
> during an
> > > earlier configuration run (not necessary except if you import
> > yacc or
> > > lex files)? Did you import some yacc or lex files?
> > >
> > > I had to install `byacc` package using yum in fedora, then I used
> the
> > > --enable-auto-regen
> > > option, that worked.
> > > However, it's still not building and I'm seeing a lot of warnings,
> I
> > > think this is because of the
> > > files I imported from the freebsd source, maybe they depend on some
> > > other headers that
> > > I didn't include. Any suggestion on how to debug, if this is the
> > case?
> > >
> > > Best regards
> > >
> > > Christian
> > >
> >
> >
> > Hello Vijay,
> >
> > normally you shouldn't need the --enable-auto-regen option. It only
> > changes a lot of files that you don't want to change. Especially: If
> you
> > use Fedora (or some other Linux) you get GPL licensed output. We
> > normally use FreeBSD for that step and check in the generated files
> so
> > that no user has to use --enable-auto-regen.
> >
> > Regarding how to start such a port: Normally it's a good idea to get
> > some overview over what's missing. For that you import the files that
> > you think are relevant (like you already did). Then you can build
> with
> > `waf -k -j1` which continues even if some files are not compilable
> (-k
> > is for continue, -j1 so that you receive the messages in order). You
> > should get a lot of compiler errors during that run.
> >
> > Now comes the hard part: You have to analyse the errors and try to
> find
> > out what's the reason for them. If some big part is missing you most
> > likely get a lot of similar errors (like "header xy.h not found").
> Most
> > likely you can identify some groups. With that you can estimate what
> has
> > to be ported besides the files you already imported.
> >
> > Identifying these groups is a quite relevant step for planning the
> > amount of work for your GSoC proposal. If you are unsure, try to ask
> on
> > the mailing list. You can also post the build output and an
> assumption
> > what groups you estimate to get some feedback.
> >
> > Best regards
> >
> > Christian
> >
> >
> > Hi
> >
> > I figured ou

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee 
wrote:

>
> Hi Christian,
>
> (it got sent by mistake :) )

Thanks for telling about the script, now I have the code imported and it's
building successfully.
I have forked the repo and created a branch with my commits. Please have a
look and see if
It's going in the right direction.
https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer

I have also wrote a first draft of the proposal. Are we supposed to send
the draft proposals only after the the application period stars? or can we
just share it offlist with the mentors now?

Thanks

>
> On Sun, 17 Mar 2019 at 14:30, Christian Mauderer 
> wrote:
>
>> Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
>> >
>> >
>> > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer > > > wrote:
>> >
>> > Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
>> > >
>> > >
>> > > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
>> > mailto:l...@c-mauderer.de>
>> > > >> wrote:
>> > >
>> > > Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
>> > > > Hello,
>> > > >
>> > > > I am trying to `./waf install` the libbsd but getting some
>> > error,
>> > > need help
>> > > > with that. The commands used and the errors are given below
>> ...
>> > > >
>> > > > configured using: `./waf configure
>> > --buildset=buildset/default.ini
>> > > > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
>> > > >
>> > > > configure was successful.
>> > > >
>> > > > then : `./waf install`
>> > > >
>> > > > Error ...
>> > > > 
>> > > > Build failed
>> > > >  -> task in 'lex__nsyy' failed with exit status 1 (run with
>> > -v to
>> > > > display more information)
>> > > >  -> task in 'yacc__nsyy' failed with exit status 1 (run with
>> > -v to
>> > > > display more information)
>> > > >  -> task in 'lex_pcap' failed with exit status 1 (run with
>> -v to
>> > > display
>> > > > more information)
>> > > >  -> task in 'yacc_pcap' failed with exit status 1 (run with
>> > -v to
>> > > > display more information)
>> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
>> > to display
>> > > > more information)
>> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
>> > to display
>> > > > more information)
>> > > >  -> task in 'yacc_pfctly' failed with exit status 1 (run
>> > with -v to
>> > > > display more information)
>> > > >
>> > > > 
>> > > >
>> > > > Thanks
>> > > > --vijay
>> > > >
>> > >
>> > > Hello Vijay,
>> > >
>> > > did you try to build before the install? I don't see the call.
>> > > Normally it's
>> > >
>> > >   waf configure ...
>> > >   waf
>> > >   waf install
>> > >
>> > > If you did that: It seems that some of the lex / yacc files
>> > should be
>> > > regenerated. Did you enable --enable-auto-regen somewhen
>> during an
>> > > earlier configuration run (not necessary except if you import
>> > yacc or
>> > > lex files)? Did you import some yacc or lex files?
>> > >
>> > > I had to install `byacc` package using yum in fedora, then I used
>> the
>> > > --enable-auto-regen
>> > > option, that worked.
>> > > However, it's still not building and I'm seeing a lot of
>> warnings, I
>> > > think this is because of the
>> > > files I imported from the freebsd source, maybe they depend on
>> some
>> > > other headers that
>> > > I didn't include. Any suggestion on how to debug, if this is the
>> > case?
>> > >
>> > > Best regards
>> > >
>> > > Christian
>> > >
>> >
>> >
>> > Hello Vijay,
>> >
>> > normally you shouldn't need the --enable-auto-regen option. It only
>> > changes a lot of files that you don't want to change. Especially:
>> If you
>> > use Fedora (or some other Linux) you get GPL licensed output. We
>> > normally use FreeBSD for that step and check in the generated files
>> so
>> > that no user has to use --enable-auto-regen.
>> >
>> > Regarding how to start such a port: Normally it's a good idea to get
>> > some overview over what's missing. For that you import the files
>> that
>> > you think are relevant (like you already did). Then you can build
>> with
>> > `waf -k -j1` which continues even if some files are not compilable
>> (-k
>> > is for continue, -j1 so that you receive the messages in order). You
>> > should get a lot of compiler errors during that run.
>> >
>> > Now comes the hard part: You have to analyse

Re: rtems-libbsd build error

[Christian Mauderer]

Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>> wrote:
> 
> 
> Hi Christian,
> 
> (it got sent by mistake :) )
> 
> Thanks for telling about the script, now I have the code imported and
> it's building successfully.
> I have forked the repo and created a branch with my commits. Please have
> a look and see if 
> It's going in the right direction. 
> https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer 
> 
> I have also wrote a first draft of the proposal. Are we supposed to send
> the draft proposals only after the the application period stars? or can
> we just share it offlist with the mentors now?
> 
> Thanks  

Hello Vijay,

first regarding the proposal:

@Joel: Please correct me if I'm wrong!

I think it should be OK to discuss the proposal as soon as you have
something. I assume you already have completed the Hello world and sent
it to at least one of our Org Admins?


Regarding the code:

Although the commits need some polishing (see * at the end) it looks
like a good start that you were already able to import and compile some
of the necessary files.

From what I've seen, you currently pulled in three parts:

1. Some part of videomode. There are some awk scripts in that directory
too so some generated files might need some processing.

2. The iic headers. That looks good. An RTEMS implementation for the
functions most likely is necessary.

3. The driver for the chip that converts from the LCD interface to an
HDMI interface. That's good and necessary too.

What is missing (which is entirely OK at the current phase) are the
following parts:

A. The LCD controller driver itself (am335x_lcd.c, ...).

B. The driver isn't referenced anywhere (normally would be done in
nexus-devices.h for devices that should be always there). So it isn't
linked into the applications yet. That's the reason that you currently
didn't get any `function not found` errors during the linking yet ;-)

C. The framebuffer interface of FreeBSD. I haven't had a detailed look
at that yet. But someone has to do something with the fb_getinfo
DEVMETHOD that is defined in am335x_lcd.c. I'm also not sure whether we
have some generic framebuffer code in RTEMS or whether we should use it
completely from libbsd.

So most likely you will find some more problems when the real work
starts. But it would be no fun if everything would run smoothly ;-)

Best regards

Christian


(*) See hints in CONTRIBUTING.md in chapter "How to Import Code from
FreeBSD". The final commits should be (for each sensible module) one
import commit where unchanged files are imported and one port commit
where the files are added to libbsd.py and necessary changes are made.


> 
> 
> On Sun, 17 Mar 2019 at 14:30, Christian Mauderer  > wrote:
> 
> Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> >     >
> >     >
> >     > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>  >     >
> >     >     Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> >     >     > Hello, 
> >     >     >
> >     >     > I am trying to `./waf install` the libbsd but
> getting some
> >     error,
> >     >     need help
> >     >     > with that. The commands used and the errors are
> given below ...
> >     >     >
> >     >     > configured using: `./waf configure
> >     --buildset=buildset/default.ini
> >     >     > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >     >     >
> >     >     > configure was successful.
> >     >     >
> >     >     > then : `./waf install`
> >     >     >
> >     >     > Error ...
> >     >     > 
> >     >     > Build failed
> >     >     >  -> task in 'lex__nsyy' failed with exit status 1
> (run with
> >     -v to
> >     >     > display more information)
> >     >     >  -> task in 'yacc__nsyy' failed with exit status 1
> (run with
> >     -v to
> >     >     > display more information)
> >     >     >  -> task in 'lex_pcap' failed with exit status 1
> (run with -v to
> >     >     display
> >     >     > more information)
> >     >     >  -> task in 'yacc_

Re: [PATCH] Add rtems_board_support_package()

[Chris Johns]

On 14/3/19 12:41 am, Sebastian Huber wrote:
> On 13/03/2019 14:39, Joel Sherrill wrote:
>> On Wed, Mar 13, 2019 at 2:38 AM Sebastian Huber
>> > > wrote:
>>
>>     What about this patch? The placement of rtems_board_support_package()
>>     into  is a bit odd, but I think it fits into the
>>     scope
>>     of these functions. You normally include  if you
>>     want
>>     to print some system information. Another place would be 
>>     right
>>     after rtems_get_version_string().
>>
>> I think it is OK although I agree with you it is odd.

+1

>>
>> If these are intended to be public APIs, I do not see any documentation for
>> them in rtems-docs.
> 
> All functions in this header are not in rtems-docs so far. I guess the primary
> use case is test meta-data output.
> 

This can also be useful for users for the same reasons we find it useful.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: erc32 dl09 Failure

[Chris Johns]

On 16/3/19 4:43 am, Joel Sherrill wrote:
> Hi
> 
> Is this the way this test fails when the BSP doesn't have enough memory?

Correct, this is a test where a lot of memory is needed. The test has to make
sure the code is loaded at offsets that are greater than the relative offsets in
the generated code.

The problem with this failure is the arch, SPARC, does not need trampoline
support and so the test is actually a `nop`. I wonder if I need to handle this
better in the test by coding the archs that need to have a suitable load offset?

Chris

> 
> *** BEGIN OF TEST libdl (RTL) 9 ***
> *** TEST VERSION: 5.0.0.2defa94c4ce2204cf5cb86d2900d8c48e7d7d781
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 7.4.0 20181206 (RTEMS 5, RSB
> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
> --
>  Run: 0
> Test source (link in strstr): testsuites/libtests/dl09/dl-load.c
> load: /dl09-o1.o
> handel: 0x206cc20: unresolved externals
> handle: 0x206cc20 loaded
> space alloc: /dl09-o1.o: 33554432: 0
> ../../../../../../rtems/c/src/../../testsuites/libtests/dl09/dl-load.c: 156
> o->space != NULL
> 
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.2defa94c4ce2204cf5cb86d2900d8c48e7d7d781
> RTEMS tools: 7.4.0 20181206 (RTEMS 5, RSB
> 38241392a4f96dabf2d1aba51a43dcb623db4dfb, Newlib 1d35a003f)
> executing thread ID: 0x08a010001
> 
> 
> ___
> 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

Re: [PATCH 2/3] Add the T Test Framework

[Chris Johns]

Hi,

I am not sure how this fits in with what we have so before I can support any
changes of this scale and direction I need to understand:

1. Are all existing tests to be converted to this new framework?

2. How does this effect the existing eco-system support such as the `rtems-test`
command and the documentation around that command?

3. What does 'T' in THE_T_TEST_FRAMEWORK_H stand for? I prefer we prefix RTEMS_
where it makes sense.

4. I see in another email you post a Sphinx generated report. What are those
tests and what is used to capture and create that report and will this in time
include all existing tests?

Chris

On 14/3/19 9:24 pm, Sebastian Huber wrote:
> Update #3199.
> ---
>  cpukit/Makefile.am|   11 +
>  cpukit/headers.am |1 +
>  cpukit/include/t.h| 2128 
> +
>  cpukit/libtest/t-test-checks-eno.c|  145 +++
>  cpukit/libtest/t-test-checks-psx.c|   17 +
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] eng: Add software test framework chapter

[Chris Johns]

On 14/3/19 9:23 pm, Sebastian Huber wrote:
> Update #3199.
> ---
>  eng/index.rst  |3 +
>  eng/test-framework.rst | 2077 
> 
>  2 files changed, 2080 insertions(+)
>  create mode 100644 eng/test-framework.rst
> 
> diff --git a/eng/index.rst b/eng/index.rst
> index fe51e91..f29d0f3 100644
> --- a/eng/index.rst
> +++ b/eng/index.rst
> @@ -11,6 +11,8 @@ RTEMS Software Engineering (|version|)
>  
>  .. topic:: Copyrights and License
>  
> +| |copy| 2018, 2019 embedded brains GmbH
> +| |copy| 2018, 2019 Sebastian Huber
>  | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR)
>  
>  .. include:: ../common/license.rst
> @@ -26,6 +28,7 @@ RTEMS Software Engineering (|version|)
>  stakeholders
>  management
>  test-plan
> +test-framework
>  release-mgmt
>  users-manuals
>  license-requirements
> diff --git a/eng/test-framework.rst b/eng/test-framework.rst
> new file mode 100644
> index 000..dda13bc
> --- /dev/null
> +++ b/eng/test-framework.rst
> @@ -0,0 +1,2077 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2018, 2019 embedded brains GmbH
> +.. Copyright (C) 2018, 2019 Sebastian Huber
> +
> +Software Test Framework
> +***
> +
> +.. _TheTTestFramework:
> +
> +The T Test Framework
> +
> +
> +The `T Test Framework` helps to write test suites.  A `test suite` is a
> +collection of test cases.  A `test case` consists of individual test actions
> +and checks.  A `test check` determines if the outcome of a test action meets
> +its expectation.  A `test action` is a program sequence with an observable
> +outcome, for example a function invocation with a return status.  If the test
> +action outcome is all right, then the test check passes, otherwise the test
> +check fails.  The test check failures of a test case are summed up.  A test
> +case passes, if the failure count of this test case is zero, otherwise the 
> test
> +case fails.  The test suite passes if all test cases pass, otherwise it 
> fails.

I think this needs a little more clarification. The density of that is being
expressed is too compact and I think it requires some expansion. For example
from this I cannot tell where an executable boundary is and given RTEMS has had
'testsuites' I feel expanding and explaining each of these is important in
relationship to what RTEMS has and needs. For example:

  The `T Test Framework` helps to write test suites.  A `test suite` is a
  collection of test cases ..

and then ...

  ... where tests for specific functionality are grouped for example
  `fstests`.

Is a test executable a collection of "test cases" or a single case? How is this
decided?

What is the expected number of tests once this SMP qual work ends? Is hardware
testing a requirement?

An outline of the problem domain being addressed would help?

Can there please be some explanation of what the issues this framework is
attempt to solve are, what it does well, what it does not do well or is not,
plus things like target requirements, test duration, etc?

I feel if this is done the detail that follows will be just that the detail.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel