On Sun, Mar 17, 2019 at 2:24 PM Joel Sherrill <j...@rtems.org> wrote:
>
>
>
> On Sun, Mar 17, 2019, 12:45 PM Vaibhav Gupta <vaibhavgupt...@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 <j...@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 <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 <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 <vaibhavgupt...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to