Valid interrupt vectors and the interrupt server

Chris Johns chrisj at rtems.org
Mon Jun 19 01:59:20 UTC 2017


On 18/06/2017 17:45, Christian Mauderer wrote:
> 
> yes the interrupt server uses an pseudo interrupt on _every_ target:
> 
> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/src/irq-server.c?id=ae359a9df#n31

Thanks.

It would be nice to have a comment that gave us a hint on what the interrupt
server's management vector is and what it is being used for in the interrupt
server (hint for this to be added).

To highlight the inconsistencies this line of code introduces consider:

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/include/irq-generic.h#n112

It states the BSP interrupt support manages from BSP_INTERRUPT_VECTOR_MIN to
BSP_INTERRUPT_VECTOR_MAX so does this means the interrupt server has defined the
management vector outside of the valid range on purpose and then knowingly makes
a call to the BSP with an invalid vector number as this code indicates:

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/src/irq-server.c?id=ae359a9df#n276
https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/src/irq-server.c?id=ae359a9df#n59

Is the interrupt server allowed to make calls to enable and disable vectors and
ignore the return code from the BSP? The comment here indicates it cannot:

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/shared/include/irq-generic.h#n214

but it is not clear, eg what is being guaranteed about the vector number? Is
this comment saying the vector number passed in must be valid? If so the
interrupt server is broken and should be fixed and not the BSPs.

I think the calling code should supply a valid vector number as the comment
indicates so the enable code can be as fast as possible. If this is true is
this patch wrong and should it be reverted:

https://git.rtems.org/rtems/commit/?id=ce3ac00c

?

Should we be adding the overhead in the enable and disable path to handle an
internal design choice in the interrupt server? I do not think so.

I would suggest the enable/disable calls return 'void' to indicate they can
never fail and an invalid vector should be a fatal error with debugging on.

This should be cleaned up for 4.12.

> That has nothing to do with the libbsd. The only connection is that libbsd uses the interrupt server for some interrupt processing.

Sure this makes sense.

Chris



More information about the devel mailing list