[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