POSIX Compilance- #2966, GSoC Project 2019

Sun Mar 17 23:10:17 UTC 2019

On Sun, Mar 17, 2019 at 2:24 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Sun, Mar 17, 2019, 12:45 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com> 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.  <function>grantpt</function> 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 <joel at rtems.org> 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 <vaibhavgupta40 at 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 <wchar.h> header
>>>> .
>>>> #3371 - Add dirfd() and fdopendir() methods in dirent.h
>>>> .
>>>> #3656 - Function prototypes for posix_fadvise() and posix_fallocate() missing in <fcntl.h> 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 <vaibhavgupta40 at gmail.com 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
>

I also just wanted to follow-up that for this particular project, you
will need to be able to build newlib and produce patches for it. I
suggest you do that during the proposal-writing period. Also, make
sure your mentor approves all patches that are intended for newlib
BEFORE you post to their mailing list. We had some issues in the past
when student patches were not in a great shape, and the newlib folks
got a little upset about having to do a lot of work that was really
the responsibility of an RTEMS Mentor.

Gedare

> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel