I need clarification on a subtle point, which exists prior to your change. It may be that I just don't understand what we mean by "The directive will not cause the calling task to be preempted.", but does rtems_interrupt_enable() and rtems_interrupt_flash() introduce a preemption point? The documentation suggests it does not, but I am not so clear. What about rtems_interrupt_lock_acquire() and rtems_interrupt_lock_release()? Similar kind of thinking applies. Calling these directives can cause a scheduling invocation due to, for example, a deferred clock tick interrupt or a block/unblock operation. This can cause the task to be preempted? Or do I misunderstand.
One more comment below for Sebastian: On Fri, Apr 23, 2021 at 7:38 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > -INTERRUPT_FLASH - Flash Interrupts > ----------------------------------- > +rtems_interrupt_flash() > +----------------------- > + > +Flashes interrupts on the current processor. > + > +.. rubric:: CALLING SEQUENCE: > + > +.. code-block:: c > + > + #define rtems_interrupt_flash( isr_cookie ) > + > +.. rubric:: PARAMETERS: > > -CALLING SEQUENCE: > - .. code-block:: c > +``isr_cookie`` > + This parameter is the previous interrupt level. > > - void rtems_interrupt_flash( > - rtems_interrupt_level level > - ); > +.. rubric:: DESCRIPTION: > > -DIRECTIVE STATUS CODES: > - NONE > +This directive is functionally equivalent to a calling delete 'a' _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
