TCP/IP update, possible SMP (GSOC 2014)

[Joel Sherrill]

On Feb 28, 2014 10:06 AM, Daniel Ramirez <javamonn at gmail.com> wrote:
>
>
>
>
> On Fri, Feb 28, 2014 at 2:20 AM, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> Hello Daniel,
>>
>>
>> On 2014-02-27 15:14, Daniel Ramirez wrote:
>>>
>>> I've seen the status page but I know Sebastian is spearheading the bulk of the
>>> work and I'm not exactly sure what would be reasonable/useful as gsoc project.
>>> What I'm specifically looking at:
>>>
>>> Migration away from task variables.
>>
>>
>> its not that much to do here, maybe one or two weeks of work.
>>
>>>
>>> Low level broadcasts.
>>
>>
>> I am not yet sure if we will need them.  Its also not time consuming, maybe one week.
>>
>>
>>>
>>> Condition variables seems like a good topic but I want to avoid conflicts with
>>> other students if possible.
>>
>>
>> Yes, condition variables are important.
>>

+1

>>>
>>> Work that needs to be done within the scheduler API that would enable SMP.
>>
>>
>> The work on the clustered/partitioned scheduling is on my high priority list, so I hope that the scheduler API will be stable before the GSoC starts.  I will provide only a fixed priority scheduler.
>
>
> So are you suggesting that work on (or within) the clustered/partitioned scheduler could possibly be an acceptable gsoc project? Or that projects requiring a stable scheduler API would be acceptable?
>
> One more SMP related idea I thought would really be interesting would be to add fine grained locking support. I'm just looking for an area that I can start really studying and narrow down a proposal.
>
>>

I am not as concerned about more schedulers for gsoc as tidying up the list of outstanding issues. Condition variables, eliminate use of unsafe constructs like per task variables in cpukit, use of disable interrupts or preempt as critical section, Newlib locking, etc.

The SMP wiki page has some and a bit of status. Addressing use of critical section techniques that are unsafe on SMP could be more work than it sounds.

>>
>>>
>>> If I'm missing something that would make for a good project and help get SMP up
>>> and running, let me know.
>>
>>
>> Some interesting area also useful for the network stack would be flattened device tree support for driver initialization and configuration.
>
>
> I will look into this, thanks.
>
>>
>> --
>> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140310/050843a5/attachment-0001.html>