RFC: Interrupt Manager Extension changes

Till Straumann strauman at slac.stanford.edu
Fri Jul 10 15:50:40 UTC 2009


I like the idea of a facility to let interrupt handlers execute
from a task context.

However, IMO it would be far more flexible and useful if there was not
just one server task (which still could be the default) but if
when installing the ISR one could optionally request a new/separate
task (with desired priority etc.).

-- Till

Sebastian Huber wrote:
> Hi,
>
> the Interrupt Manager Extension is documented here:
>
> http://www.rtems.com/doxygen/cpukit/html/group__rtems__interrupt__extension.html
>
> In order to support the legacy API and FreeBSD interrupt handlers better I
> would like to change the interrupt handler signature from
>
> typedef void (*rtems_interrupt_handler)(rtems_vector_number, void *);
>
> to
>
> typedef void (*rtems_interrupt_handler)(void *);
>
> The current signature was primarily chosen to support the Classic API in the
> future without overhead.  This turned out to be impractical.
>
> I would also like to change the return code for requests with an invalid vector
> number from RTEMS_INVALID_NUMBER to RTEMS_INVALID_ID since the vector number
> acts like an object ID in this context.
>
> I would like to add a new API for interrupt handlers which should be executed
> within a task context:
>
> /**
>  * @brief Initializes the interrupt server task.
>  *
>  * The task will have the priority @a priority, the stack size @a stack_size,
>  * the modes @a modes and the attributes @a attributes.  Interrupt handlers can
>  * be installed on the server with rtems_interrupt_server_handler_install() and
>  * removed with rtems_interrupt_server_handler_remove().  In case of an
>  * interrupt the request will be forwarded to the server.  The handlers are
>  * executed within the server context.  If one handler blocks on something this
>  * may delay the processing of other handlers.
>  *
>  * @note This function may block.
>  *
>  * @return
>  * - On success @c RTEMS_SUCCESSFUL shall be returned.
>  * - If the interrupt server task is already initialized
>  *   @c RTEMS_INCORRECT_STATE shall be returned.
>  * - Other error states are BSP specific.
>  */
> rtems_status_code rtems_interrupt_server_initialize(
>   rtems_task_priority priority,
>   size_t stack_size,
>   rtems_mode modes,
>   rtems_attribute attributes
> );
>
> /**
>  * @brief Installs the interrupt handler routine @a handler for the interrupt
>  * vector with number @a vector.
>  *
>  * The handler routine will be executed on the interrupt server task.
>  *
>  * @note This function may block.
>  *
>  * @see rtems_interrupt_handler_install().
>  *
>  * @return
>  * - On success @c RTEMS_SUCCESSFUL shall be returned.
>  * - If the interrupt handler server is not initialized
>  *   @c RTEMS_INCORRECT_STATE shall be returned.
>  * - For other errors see rtems_interrupt_handler_install().
>  */
> rtems_status_code rtems_interrupt_server_handler_install(
>   rtems_vector_number vector,
>   const char *info,
>   rtems_option options,
>   rtems_interrupt_handler handler,
>   void *arg
> );
>
> /**
>  * @brief Removes the interrupt handler routine @a handler with argument @a arg
>  * for the interrupt vector with number @a vector.
>  *
>  * @note This function may block.
>  *
>  * @see rtems_interrupt_handler_remove().
>  *
>  * @return
>  * - On success @c RTEMS_SUCCESSFUL shall be returned.
>  * - If the interrupt handler server is not initialized
>  *   @c RTEMS_INCORRECT_STATE shall be returned.
>  * - For other errors see rtems_interrupt_handler_remove().
>  */
> rtems_status_code rtems_interrupt_server_handler_remove(
>   rtems_vector_number vector,
>   rtems_interrupt_handler handler,
>   void *arg
> );
>
> Have a nice day!
>
>   




More information about the users mailing list