SuperCore Scheduler (GSOC 2014)

[Andre Marques]

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.