Re: GSoC: Guidance for POSIX Compilance

[Aditya Upadhyay]

Hi Vaibhav,

I saw your doubts on devel mailing list regarding the newlib-c.
These are the points, you should know about newlib c and
why does most embedded system use newlib c as runtime library.

newlib c is used to provide supports to the different platforms and
architecute specific compilers.
For example:
if you have a compiled binary and that you want to run it on a
particular platform
then this newlib c is used by compiler to invoke some of the built-in functions
in that runtime environment.
Some low level routines are defined inside the newlib-cygwin that provides
architecture support. For example: Stack, Heap, memory management,
interrupt facilities is
defined in the newlib c and these implementation is architecture dependent.

On Sun, Mar 17, 2019 at 10:02 AM Vaibhav Gupta  wrote:
>
> Hello Aditya,
>
> First of all Congratulations for your successful completion of POSIX 
> Compilance Project in RTEMS in 2017.
> .
> I read your proposal and its impressive. You seem to have done lot of 
> homework on RTEMS that
> time.
> .
> I am a 2nd year student from JIIT Noida and I am preparing to take same 
> project (POSIX Compilance) this year for GSoC.
> .
> I had doubts and asked them on mailing list, then Gedare suggested me to take 
> advice from you as you also went with same processes at your time which I am 
> facing now.
> .
For more, You can look into this:
https://www.embedded.com/design/prototyping-and-development/4024867/Embedding-with-GNU-Newlib
Above link will help you to understand other term like reentrancy concept
when you will be going to provide supports in the multi-threaded environment.
To understand licensing terms, You can refer here. It will help to
figure out the
difference between the glibc, newlibc, klibc etc..
https://groups.google.com/forum/#!topic/native-client-discuss/_OAQsL77kPQ

> It would be great if you can help me out.
>
I would encourage you to test this inttypes test suite code, What
I have not yet committed. You just need to change some copyrights things.
It would be appreciated if you send a patch on devel. It will help you to
understand the code flow and relation between the newlib c and rtems.
inttypes methods test suite location:
https://drive.google.com/open?id=1vnb0KBhkYLTPzbRJPMuwsnyWLP694VAa

> Thanks
> Vaibhav Gupta

Thanks,
Aditya Upadhyay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

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 out that there were some unnecessary imports I was doing and
> also some necessary
> header files that I'm missing, after adding those most of the warnings
> vanished. The error I'm
> seeing now is due to a missing '.m' header file. The error looks like
> this ...
> =
>    ../../freebsd/sys/arm/ti/am335x/tda19988.c:56:10: fatal 

Re: GSoC: Guidance for POSIX Compilance

[Vaibhav Gupta]

On Sun, Mar 17, 2019 at 2:10 PM Aditya Upadhyay  wrote:

> Hi Vaibhav,
>
> I saw your doubts on devel mailing list regarding the newlib-c.
> These are the points, you should know about newlib c and
> why does most embedded system use newlib c as runtime library.
>
> newlib c is used to provide supports to the different platforms and
> architecute specific compilers.
> For example:
> if you have a compiled binary and that you want to run it on a
> particular platform
> then this newlib c is used by compiler to invoke some of the built-in
> functions
> in that runtime environment.
> Some low level routines are defined inside the newlib-cygwin that provides
> architecture support. For example: Stack, Heap, memory management,
> interrupt facilities is
> defined in the newlib c and these implementation is architecture dependent.
>
> On Sun, Mar 17, 2019 at 10:02 AM Vaibhav Gupta 
> wrote:
> >
> > Hello Aditya,
> >
> > First of all Congratulations for your successful completion of POSIX
> Compilance Project in RTEMS in 2017.
> > .
> > I read your proposal and its impressive. You seem to have done lot of
> homework on RTEMS that
> > time.
> > .
> > I am a 2nd year student from JIIT Noida and I am preparing to take same
> project (POSIX Compilance) this year for GSoC.
> > .
> > I had doubts and asked them on mailing list, then Gedare suggested me to
> take advice from you as you also went with same processes at your time
> which I am facing now.
> > .
> For more, You can look into this:
>
> https://www.embedded.com/design/prototyping-and-development/4024867/Embedding-with-GNU-Newlib
> Above link will help you to understand other term like reentrancy concept
> when you will be going to provide supports in the multi-threaded
> environment.
> To understand licensing terms, You can refer here. It will help to
> figure out the
> difference between the glibc, newlibc, klibc etc..
> https://groups.google.com/forum/#!topic/native-client-discuss/_OAQsL77kPQ
>
> > It would be great if you can help me out.
> >
> I would encourage you to test this inttypes test suite code, What
> I have not yet committed. You just need to change some copyrights things.
> It would be appreciated if you send a patch on devel. It will help you to
> understand the code flow and relation between the newlib c and rtems.
> inttypes methods test suite location:
> https://drive.google.com/open?id=1vnb0KBhkYLTPzbRJPMuwsnyWLP694VAa

I did try to run it with following command:
sparc-rtems5-gcc -B/home/varodek/development/rtems/5/sparc-rtems5/erc32/lib
-specs bsp_specs -qrtems -mcpu=cypress -O2 -g -ffunction-sections
-fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress init.c

it gives me error:

init.c:9:10: fatal error: tmacros.h: No such file or directory
 #include 
  ^~~
compilation terminated.

Though the headerfile is located at
/home/varodek/development/rtems/kernel/rtems/testsuites/support/include/tmacros.h


>
> > Thanks
> > Vaibhav Gupta
>
> Thanks,
> Aditya Upadhyay
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

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

I track compliance against every standard I can find.

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: GSoC: Guidance for POSIX Compilance

[Joel Sherrill]

On Sun, Mar 17, 2019, 6:18 AM Vaibhav Gupta 
wrote:

>
>
> On Sun, Mar 17, 2019 at 2:10 PM Aditya Upadhyay 
> wrote:
>
>> Hi Vaibhav,
>>
>> I saw your doubts on devel mailing list regarding the newlib-c.
>> These are the points, you should know about newlib c and
>> why does most embedded system use newlib c as runtime library.
>>
>> newlib c is used to provide supports to the different platforms and
>> architecute specific compilers.
>> For example:
>> if you have a compiled binary and that you want to run it on a
>> particular platform
>> then this newlib c is used by compiler to invoke some of the built-in
>> functions
>> in that runtime environment.
>> Some low level routines are defined inside the newlib-cygwin that provides
>> architecture support. For example: Stack, Heap, memory management,
>> interrupt facilities is
>> defined in the newlib c and these implementation is architecture
>> dependent.
>>
>> On Sun, Mar 17, 2019 at 10:02 AM Vaibhav Gupta 
>> wrote:
>> >
>> > Hello Aditya,
>> >
>> > First of all Congratulations for your successful completion of POSIX
>> Compilance Project in RTEMS in 2017.
>> > .
>> > I read your proposal and its impressive. You seem to have done lot of
>> homework on RTEMS that
>> > time.
>> > .
>> > I am a 2nd year student from JIIT Noida and I am preparing to take same
>> project (POSIX Compilance) this year for GSoC.
>> > .
>> > I had doubts and asked them on mailing list, then Gedare suggested me
>> to take advice from you as you also went with same processes at your time
>> which I am facing now.
>> > .
>> For more, You can look into this:
>>
>> https://www.embedded.com/design/prototyping-and-development/4024867/Embedding-with-GNU-Newlib
>> Above link will help you to understand other term like reentrancy concept
>> when you will be going to provide supports in the multi-threaded
>> environment.
>> To understand licensing terms, You can refer here. It will help to
>> figure out the
>> difference between the glibc, newlibc, klibc etc..
>> https://groups.google.com/forum/#!topic/native-client-discuss/_OAQsL77kPQ
>>
>> > It would be great if you can help me out.
>> >
>> I would encourage you to test this inttypes test suite code, What
>> I have not yet committed. You just need to change some copyrights things.
>> It would be appreciated if you send a patch on devel. It will help you to
>> understand the code flow and relation between the newlib c and rtems.
>> inttypes methods test suite location:
>> https://drive.google.com/open?id=1vnb0KBhkYLTPzbRJPMuwsnyWLP694VAa
>
> I did try to run it with following command:
> sparc-rtems5-gcc
> -B/home/varodek/development/rtems/5/sparc-rtems5/erc32/lib -specs bsp_specs
> -qrtems -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall
> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
> -Wnested-externs -Wl,--gc-sections -mcpu=cypress init.c
>
> it gives me error:
>
> init.c:9:10: fatal error: tmacros.h: No such file or directory
>  #include 
>   ^~~
> compilation terminated.
>
> Though the headerfile is located at
> /home/varodek/development/rtems/kernel/rtems/testsuites/support/include/tmacros.h
>

That file is in the RTEMS source tree. His test needs to be built as part
of the test suite.

And did I miss meeting a patch for this? If it is ready, please poke me
with where to get it.

Sorry.

>
>
>
>>
>> > Thanks
>> > Vaibhav Gupta
>>
>> Thanks,
>> Aditya Upadhyay
>>
> ___
> 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: POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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]

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.

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
>>
>>
>>
>> On Thu, 7 Mar, 2019, 9:57 PM Vaibhav Gupta > wrote:
>>
>>> Hello,
>>> I was exploring open projects and got very much intrested in the
>>> following ticket:
>>>
>>> #2966 - POSIX Compilance : https://devel.rtems.org/ticket/2966
>>> .
>>> As on the page, the project is divided into multiple sub-tasks. For many
>>> of them I am not able to find their current status and if enough work is
>>> left on them to be included as a GSoC project.
>>> .
>>> I would like to know the good combinations of sub-tasks which can
>>> compile into a good GSoC project under the "POSIX" ticket. I am very much
>>> interested to take this project. It would be great if someone mentors this
>>> project, I want to discuss further on this.
>>> .
>>> Also if there are new any new projects which are not mentioned on
>>> open-projects page? That can be taken up as GSoC project, I would love to
>>> explore them as well.
>>>
>>> Thankyou
>>> Vaibhav Gupta
>>>
>>
___
devel mai

Re: POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

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
>>>
>>>
>>>
>>> On Thu, 7 Mar, 2019, 9:57 PM Vaibhav Gupta >> wrote:
>>>
 Hello,
 I was exploring open projects and got very much intrested in the
 following ticket:

 #2966 - POSIX Compilance : https://devel.rtems.org/ticket/2966
 .
 As on the page, the project is divided into multiple sub-tasks. For
 many of them I am not able to find their current status and if enough work
 is left on them to be included as a GSoC project.
 .
 I

Re: POSIX Compilance- #2966, GSoC Project 2019

[Gedare Bloom]

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



 On Thu, 7 Mar, 2019, 9:57 PM Vaibhav Gupta 
> Hello,
> I was exploring open projects and got very much intrested in the 
> following ticket:
>
> #2966 - POSIX Compilance : https://devel.rtems.org/ticket/2966
> .
>