[PATCH] tests: CONFIGURE_DISABLE_SMP_CONFIGURATION

Gedare Bloom gedare at rtems.org
Wed May 17 00:34:40 UTC 2017


On Tue, May 16, 2017 at 6:40 PM, Chris Johns <chrisj at rtems.org> wrote:
> On 16/05/2017 18:35, Sebastian Huber wrote:
>>
>> On 16/05/17 10:28, Chris Johns wrote:
>>>
>>> What we do need to do is make sure the test results express the true
>>> state. If a test is broken it should fail. If it is tagged an
>>> expected-fail we do not consider it a regression.
>>
>>
>> Loosing test coverage simply because a test uses a non-SMP feature somehow
>> is not really great.
>>
>
> I am sorry you have lost me. If the test is for something not available when
> SMP is enabled why build it? This can be handled in the build system. If the
> test is using something not available on SMP and it can be written to work
> on SMP by not using that feature then the test is broken on SMP and I would
> expect a fail until it is fixed.
>
There is value in retaining uniprocessor tests whose patterns break on
SMP because the patterns are not safe for parallel threads. I would
just leave those as expected-fail.

> Chris
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



More information about the devel mailing list