On Fri, Feb 28, 2014 at 2:20 AM, Sebastian Huber < sebastian.hu...@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. > > > >> 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. > > > >> 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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
