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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel