GSOC 2015 - SMP Projects
Sebastian Huber
sebastian.huber at embedded-brains.de
Wed Mar 11 08:33:14 UTC 2015
On 10/03/15 22:20, Joel Sherrill wrote:
>
> On 3/10/2015 4:18 PM, Joel Sherrill wrote:
>> On 3/10/2015 10:04 AM, Gedare Bloom wrote:
>>> On Tue, Mar 10, 2015 at 10:19 AM, Rohini Kulkarni <krohini1593 at gmail.com> wrote:
>>>> Hi All,
>>>> I am interested in doing a project under SMP (Improvements to SMP support).
>>>> Are there any suitable SMP projects which can be undertaken as part of GSOC.
>>>> However,I do not have an experience with such kind of development.
>>>>
>>> You might like to consider improving the x86-SMP support. Currently
>>> there is no one maintaining it, so there is some maintenance work to
>>> do such as [1], and there may be some improvement as well in the
>>> interrupt handling. This would require some x86 assembly if you know
>>> it or are comfortable learning it.
>>>
>>> You could also look into extending the existing SMP support to other
>>> BSPs in SPARC, ARM, or PowerPC, or in porting another architecture to
>>> SMP.
>> Gedare and I chatted earlier so let me rattle off some ideas:
>>
>> + x86 context switch hand off (#2183)
For someone with x86 knowledge this should be a one hour job.
>> + x86 proper APIC support
>> + rtems_ada_self is broken on SMP (#2289) - switch to pthread keys
The Ada self context is part of the TCB, so a simple wrapper function
should do it, like __getreent().
>> + object extend on SMP (#2280)
The problem with this task is that we don't know which level of support
we need. It ranges from not supporting object extend on SMP to something
that uses hazard pointers (patent issues need to be considered).
>> + other tickets with SMP in the description or component
I don't see anything suitable for a GSoC project in the SMP area.
> Should have mentioned that Thread Local Storage (TLS) may not be
> available on all architectures so adding that where supported by
> gcc would be beneficial.
>> Although a lot has been done, there is a lot left to be done. And
>> a ticket doesn't necessarily equal a bug for us. We are trying to
>> use tickets to track all ideas for work.
>>> There continues to be a lot of ongoing SMP work documented here [2].
>>> You may like to browse the list and ask if any of those are possibly
>>> good options.
>>>
>>> [1] https://devel.rtems.org/ticket/2183
>>> [2] https://devel.rtems.org/wiki/Developer/SMP
>>>
>>>> Thanks!
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list