On Sun, Jun 18, 2017 at 9:59 PM, Chris Johns <chr...@rtems.org> wrote: > 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. > +1
You have put my thoughts into words quite well. >> 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel