On Tue, May 16, 2017 at 6:40 PM, Chris Johns <chr...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
