Uniprocessor Tests in SMP Configuration

[Chris Johns]

On 19/02/2014 3:28 am, Joel Sherrill wrote:
>
> On 2/18/2014 10:20 AM, Gedare Bloom wrote:
>> On Tue, Feb 18, 2014 at 10:19 AM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> git
>>> On 2/18/2014 1:12 AM, Sebastian Huber wrote:
>>>> Hello Joel,
>>>>
>>>> On 2014-02-17 18:08, Joel Sherrill wrote:
>>>>> Hi
>>>>>
>>>
>>> FWIW It may be better to not build task variables than to just return an
>>> error. That is an entire class of capability that is not supported in
>>> SMP. The tests for that would fail to link and could then just be
>>> disabled from building.
>>>
>> I'd rather leave the tests as failing than to disable them. Eventually
>> they should work if task variables get fixed?
> Task variables are fundamentally and conceptually broken for SMP systems.

Maybe we should remove the task variable API from RTEMS. To support SMP 
we need to have a suitable alternative and there is no reason this 
cannot be used in uni-processor systems. That could be mean code cannot 
be written assuming task variables.

> One underlying assumption is that if it isn't safe in SMP, then we need
> to find a way to
> "break" applications in an explicit as possible way. This encourages
> application developers
> to fix the issues before they find subtle bugs on target.

Should we keep APIs that are not compatible ? I say no we should not.

Keeping them means users needs to be aware of the differences and to 
manage them when writing applications that may move between 
uni-processor and SMP systems. If the APIs do not exist this is not a 
factor. I also suspect the easiest way to this is not to use them.

To implement this we remove task variables and the pre-emption defines 
for SMP builds and flag the them as deprecated in disabled SMP builds 
then remove in the next release.

Chris