On 2014-04-09 13:17, Joel Sherrill wrote:

On Apr 9, 2014 1:06 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> 
wrote:
 >
 > On 2014-04-08 17:09, Jennifer Averett wrote:
 > > I thought the consensus was that non-smp systems would not
 > > support affinity methods.
 >
 > I don't remember a discussion about this.
 >
 > I think it makes it easier for application developers if the don't have to
 > plaster their code with #ifdef RTEMS_SMP.  You should also be able to write
 > libraries that work with SMP and non-SMP configurations.  For this we have to
 > provide the same ABI.  This should be the long term goal.

Ironically this is exactly what we have not done with disable preemption and
task variables.

Originally it was a run-time error. Usage of RTEMS_PREEMPT is still a run-time error. Maybe the removal of the task variables API for SMP was a bit too fast.


 > I propose to add a new requirement:
 >
 > The non-SMP and SMP RTEMS Classic API should be ABI compatible.
 >
 > http://www.rtems.org/wiki/index.php?title=SMP#Requirements

So you propose to defer compile errors for task variables to run time?

I am not sure. The task variables are a broken concept even on non-SMP configurations.


 > On Linux you can use the thread affinity functions also on non-SMP systems.

For this I do not mind but we did discuss this at the beginning of the
implementation.

The short circuit logic for non-smp should be in the api level code and the
score should have NO code for affinity.

Since the affinity support is used by the Classic and POSIX API it must stay in the score.


Otherwise you impact the minimum profile and this is 100% unacceptable.

There is no overhead in the non-SMP configurations if you don't use the task set/get affinity functions. The scheduler get/set affinity operations are only available in SMP configurations.

--
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

Reply via email to