On Feb 28, 2014 10:06 AM, Daniel Ramirez <javam...@gmail.com> wrote: > > > > > 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. >>
+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.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
