Uniprocessor Tests in SMP Configuration

Joel Sherrill Joel.Sherrill at OARcorp.com
Mon Feb 24 08:09:39 UTC 2014


On Feb 24, 2014 2:17 AM, Gedare Bloom <gedare at rtems.org> wrote:
>
> 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.huber at 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;
> > }

I am missing some detail here. Can you provide details?

> > POSIX keys should be moved outside the RTEMS_POSIX_API scope.

I almost completed this on the flight over to Munich. Just needs a bit more testing in different build configurations.

> >
> > 3. Disable the task variables via pre-processor on SMP and remove the
> > run-time check.

I started this but it will break the code that uses them when configured for SMP.

> >
> > 4. Add condition variables to the Classic API.

This is beyond airplane coding.;)

> >
> > 5. Use alternatives to disabled preemption for all RTEMS support components,
> > e.g. bdbuf.

We need to make a list of these and propose alternatives. GSOC project possible

> > 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.huber at 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 at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-devel
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140224/d5a139ce/attachment-0001.html>


More information about the devel mailing list