<p dir="ltr"><br>
On Apr 9, 2014 1:06 AM, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:<br>
><br>
> On 2014-04-08 17:09, Jennifer Averett wrote:<br>
> > I thought the consensus was that non-smp systems would not<br>
> > support affinity methods.<br>
><br>
> I don't remember a discussion about this.<br>
><br>
> I think it makes it easier for application developers if the don't have to <br>
> plaster their code with #ifdef RTEMS_SMP.  You should also be able to write <br>
> libraries that work with SMP and non-SMP configurations.  For this we have to <br>
> provide the same ABI.  This should be the long term goal.</p>
<p dir="ltr">Ironically this is exactly what we have not done with disable preemption and task variables.</p>
<p dir="ltr">> I propose to add a new requirement:<br>
><br>
> The non-SMP and SMP RTEMS Classic API should be ABI compatible.<br>
><br>
> http://www.rtems.org/wiki/index.php?title=SMP#Requirements</p>
<p dir="ltr">So you propose to defer compile errors for task variables to run time? <br></p>
<p dir="ltr">> On Linux you can use the thread affinity functions also on non-SMP systems.</p>
<p dir="ltr">For this I do not mind but we did discuss this at the beginning of the implementation. </p>
<p dir="ltr">The short circuit logic for non-smp should be in the api level code and the score should have NO code for affinity.</p>
<p dir="ltr">Otherwise you impact the minimum profile and this is 100% unacceptable.</p>
<p dir="ltr">> -- <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>
</p>