<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 20, 2018 at 8:26 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21/02/2018 01:23, Sebastian Huber wrote:<br>
> ----- Am 19. Feb 2018 um 12:41 schrieb Matthew J Fletcher <a href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>:<br>
><br>
>> Hi,<br>
>><br>
>> I've seen this in our application in certain use cases, if my understanding<br>
>> is correct (an it might not be), it comes<br>
>> from RTEMS_SCORE_ROBUST_THREAD_<wbr>DISPATCH,<br>
>> via CPU_ENABLE_ROBUST_THREAD_<wbr>DISPATCH.<br>
>><br>
>> It only seems to be TRUE for Arm, which seems a bit inconstant. However i<br>
>> dont really understand what its trying to achieve, i see<br>
>> <a href="https://devel.rtems.org/ticket/2954" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/2954</a> but it does more than just optimise the<br>
>> context switch, it significantly alters how an application should be<br>
>> written, no more freeing memory with interrupts disabled etc,<br>
><br>
> Originally, the CPU_ENABLE_ROBUST_THREAD_<wbr>DISPATCH was implemented for the SMP support (inter-processor interrupt delivery MUST be possible during operating system services). On ARMv7-M it catches an undefined behaviour case. On the other ARM variants it simplified the context switch code. In general, we could enable the CPU_ENABLE_ROBUST_THREAD_<wbr>DISPATCH on all architectures. This would probably break some broken applications.<br>
<br>
</span>This is a bit messy because it is clearly wrong on SMP while the Classic API's<br>
`rtems_task_create` [1] lets a user set the mask level which is almost saying<br>
"run a task at a specific mask level". I am not aware of an API call that lets a<br>
user change this level and an interrupt disable and restore returns the task's<br>
initial level so at some point being able to block with a specific mask level<br>
was a requirement. Also on modern processors levels are handled in interrupt<br>
controllers and not in the CPU so how much use is an initial mask level these days?<br></blockquote><div><br></div><div>rtems_task_mode() lets you change the interrupt mode dynamically.</div><div><br></div><div>FWIW I don't know that this feature ever was a good idea and I would be</div><div>OK with obsoleting the ability to alter the interrupt level via task mode. But</div><div>that doesn't prevent a user from using other mechanisms including their</div><div>own inline assembly from disabling processor interrupts.</div><div><br></div><div>Now get off my lawn and let me tell you how long this feature has been hokey.</div><div>Of the six earliest RTEMS ports (m68k, i386, i960, powerpc, hppa, and sparc),</div><div>the m68k, i960, and sparc could meaningfully map the interrupt level in mode</div><div>on to something at the processor. The old PowerPC's only had external exception</div><div>and decrementer interrupts. The i386 only has on and off but in all real implementations</div><div>(e.g. PCs) has external interrupt controller. The hppa had on/off as I recall but</div><div>the port/BSP had a clever feature where unused integer values mapped to</div><div>configurable settings of the interrupt controller.</div><div><br></div><div>This feature is inherently non-portable if you depend on a "level" other than</div><div>on and off.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am personally OK with a change to catch interrupts being masked in a context<br>
switch because it is more likely this happens in error than on purpose and<br>
catching this type of error without an internal check like this is hard. The<br>
flow on of this is making obsolete setting the level on a task create.<br></blockquote><div><br></div><div>Agreed.</div><div><br></div><div>But calling the "robust" implies there a regular context switch isn't robust. This</div><div>implies we don't normally switch enough registers or something. Perhaps </div><div>a better word is needed for this feature.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I suspect setting the interrupt level on a task on an ARMv-7 would result in the<br>
internal error if the user did not clear the interrupt mask before calling a<br>
blocking call. This complicates the documentation because of per arch differences.<br></blockquote><div><br></div><div>Is this a hardware feature? I wouldn't be unhappy with this being a generic check.</div><div><br></div><div>I know it has been possible to do this for 30 years but banning it wouldn't be a</div><div>bad thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, the documentation should be updated noting the SMP exceptions. I have<br>
raised #3309 to track this.<br></blockquote><div><br></div><div>We recently went through this discussion for just SMP. It would be simpler to just</div><div>obsolete the feature entirely. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> You should never call an operating system service with interrupts disabled in thread context. This would destroy all the work done in the RTEMS implementation to keep the interrupt latency small.<br>
<br>
</span>I agree and so I question if we should allow a task's initial mask level to be<br>
set this way?<br>
<br>
My rational is making the API consistent on non-SMP and SMP targets and helping<br>
to isolate a difficult case to catch.<br></blockquote><div><br></div><div>I agree with this rationale on this feature.</div><div><br></div><div>But we should all remember that no matter what we do the</div><div>user and system integrator can easily destroy the performance of a system in</div><div>a way that reflects poorly on RTEMS. As someone I work with loves to say,</div><div>"You can't prevent stupid." :)</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
<br>
[1]<br>
<a href="https://docs.rtems.org/branches/master/c-user/task_manager.html#task-create-create-a-task" rel="noreferrer" target="_blank">https://docs.rtems.org/<wbr>branches/master/c-user/task_<wbr>manager.html#task-create-<wbr>create-a-task</a><br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div></div>