Valid interrupt vectors and the interrupt server

[Gedare Bloom]

On Sun, Jun 18, 2017 at 9:59 PM, Chris Johns <chrisj at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel