On 03/10/14 07:37, Sebastian Huber wrote:
On 2014-03-09 18:51, Andre Marques wrote:
The problem is everything in the SMP task list seems to be already
under way.
Maybe it would be better for me to focus outside SMP for GSoC.
For POSIX I could:
- Continue rename() test case (including the issues I have postponed
until now)
and then make rename() POSIX conformant
- Implement lio_listio() (the only function that seems unimplemented at
http://www.rtems.org/wiki/index.php/POSIX_Asynchronous_IO)
- Test POSIX FIFOS (http://www.rtems.org/wiki/index.php/POSIXFIFOs)
- Solve some issues with newlib
(http://www.rtems.org/wiki/index.php/POSIX_Methods_in_NewLib_RTEMS_improvements)
What do you think?
Another topic might be the Newlib locking:
https://www.rtems.org/bugzilla/show_bug.cgi?id=1247
From what I understood, Newlib locking would require the implementation
of the methods in [newlib]/newlib/libc/include/sys/lock.h on
cpukit/libcsupport/ and patch newlib to use that implementation for rtems?
Would this be a GSoC project on itself?
I added support for the openat() etc. functions in Newlib for RTEMS
early this year:
https://sourceware.org/ml/newlib/2014/msg00000.html
Implementing these functions is suitable for a GSoC project. These
functions can be used to simplify the FTP server and the
rtems_tarfs_load() function for example.
Implementing those functions could also lead to making rename() posix
conformant (as renameat() is an extension of rename()) and to the test
of posix fifos (as an extension of mkfifoat() testing). I would prefer
working on Newlib locking, but this could also be of interest.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
