Valid interrupt vectors and the interrupt server
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:
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:
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:
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:
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:
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.
More information about the devel