[PATCH 3/3] score: Task get/set affinity

[Chris Johns]

On 9/04/2014 9:27 pm, Sebastian Huber wrote:
> On 2014-04-09 13:17, Joel Sherrill wrote:
>>
>> On Apr 9, 2014 1:06 AM, Sebastian Huber
>> <sebastian.huber at 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.

Task variables are broken on many levels and there are suitable 
alternatives. Removing them should have happened long ago. The 
RTEMS_PREEMPT is a good example of something we will keep and support 
for legacy reasons.

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

Yeap I agree.

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

Conditionally removed on uniprocessor builds ?

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

Could you please elaborate ? If I do not use the functions the score 
includes no extra code related to this API, ie the scope is limited to 
the API layer ?

Chris