Uniprocessor Tests in SMP Configuration
gedare at rtems.org
Tue Feb 18 16:20:29 UTC 2014
On Tue, Feb 18, 2014 at 10:19 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> On 2/18/2014 1:12 AM, Sebastian Huber wrote:
>> Hello Joel,
>> On 2014-02-17 18:08, Joel Sherrill wrote:
>>> Has anyone reviewed the results yet?
>> I executed the tests during development of the SMP priority scheduler. All
>> tests using unimplemented features fail.
> And these are expected fails but is there a list of expected fails? The
> impact of
> those on coverage evaluated?
> I know our testing framework is poor and in the process of being improved
> but this is important information.
>>> With at least no-preempt and ISR disable level not honored
>>> in the thread mode when SMP is enabled, I would assume
>>> multiple tests are expected to break.
>> I collected unsupported features in SMP mode here:
>> What do you mean with "ISR disable level not honored in the thread mode when
>> SMP is enabled"?
> I misremembered the SMP conditionals in taskmode.c. Only no-preempt is
> 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?
> Disable preemption is more subtle. The tests of rtems_task_mode()
> need addressing. But other tests simply will not work. The impact on
> coverage is unknown.
> Each feature not supported in SMP needs careful evaluation.
And analysis whether the feature will be supported in the future or if
it is uni-processor only.
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the devel