[PATCH] c-user: Generate interrupt manager documentation

Gedare Bloom gedare at rtems.org
Mon Apr 26 18:30:50 UTC 2021


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.huber at 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'


More information about the devel mailing list