Any of 2, 4, and 5 could be made into reasonable GSoC projects if we get accepted as an org?
On Sun, Feb 23, 2014 at 5:14 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > Hello, > > I would do the following. > > 1. Implement the thread deletion on SMP. I will work on this after the > profiling. > > http://www.rtems.org/wiki/index.php/SMP#Thread_Delete.2FRestart > > 2. Use alternatives to task variables for all RTEMS support components, e.g. > the file system environment. Here we can use __getreent() for example with > > struct S { > struct _reent reent; > rtems_user_env_t env; > } > > POSIX keys should be moved outside the RTEMS_POSIX_API scope. > > 3. Disable the task variables via pre-processor on SMP and remove the > run-time check. > > 4. Add condition variables to the Classic API. > > 5. Use alternatives to disabled preemption for all RTEMS support components, > e.g. bdbuf. > > 6. Disable RTEMS_PREEMT via pre-processor on SMP and remove the run-time > check. > > We (= embedded brains) have currently only a budget for 1. > > > -- > 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
