<p dir="ltr"><br>
On Feb 21, 2014 8:25 AM, Gedare Bloom <gedare@rtems.org> wrote:<br>
><br>
> On Fri, Feb 21, 2014 at 3:00 AM, Sebastian Huber<br>
> <sebastian.huber@embedded-brains.de> wrote:<br>
> > On 2014-02-20 21:07, Jennifer Averett wrote:<br>
> >><br>
> >> +#if __RTEMS_HAVE_SYS_CPUSET_H__ && defined( RTEMS_SMP )<br>
> >> +const Cpuset_Control *_Cpuset_Handler_default(void);<br>
> >> +#else<br>
> >> +#define _Cpuset_Handler_default()   do { } while ( 0 )<br>
> >> +#endif<br>
> ><br>
> ><br>
> > In case the C library doesn't provide an appropriate <sys/cpuset.h> then we<br>
> > should provide our own header file.  Maybe we should use a special header<br>
> > file that either uses <sys/cpuset.h> directly or alternatively provides the<br>
> > missing declarations and functions.<br>
> ><br>
> > I don't think it makes sense to use a SMP configuration with this API.<br>
> ><br>
> Do you mean UP?</p>
<p dir="ltr">Whether it makes sense to use UP or not is independent of the fact that Newlib always has the header. So we test it. The Score code should be disabled because it makes no sense.</p>
<p dir="ltr">We discussed SMP APIs on UP systems (on list) when we started the design. I recall no one caring if they were disabled.</p>
<p dir="ltr">Making them work UP requires more work and they can't do much anyway except error check the arguments.</p>
<p dir="ltr">If that's what we want, it can be addressed once things are in.</p>
<p dir="ltr">But there are things that break or are not present from UP to SMP so I see little reason to work on the reverse.</p>
<p dir="ltr">> ><br>
> > --<br>
> > Sebastian Huber, embedded brains GmbH<br>
> ><br>
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> > Phone   : +49 89 189 47 41-16<br>
> > Fax     : +49 89 189 47 41-09<br>
> > E-Mail  : sebastian.huber@embedded-brains.de<br>
> > PGP     : Public key available on request.<br>
> ><br>
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> > _______________________________________________<br>
> > rtems-devel mailing list<br>
> > rtems-devel@rtems.org<br>
> > http://www.rtems.org/mailman/listinfo/rtems-devel<br>
><br>
> _______________________________________________<br>
> rtems-devel mailing list<br>
> rtems-devel@rtems.org<br>
> http://www.rtems.org/mailman/listinfo/rtems-devel<br>
</p>