Wrap Interrupt Handlers for Recording?
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu Sep 5 04:25:46 UTC 2019
----- Am 4. Sep 2019 um 23:41 schrieb Chris Johns chrisj at rtems.org:
> On 5/9/19 2:09 am, Sebastian Huber wrote:
>> Hello,
>>
>> I would like to wrap calls to interrupt handlers which use the generic interrupt
>> framework (<rtems/irq-extension.h>) to get RTEMS_RECORD_INTERRUPT_ENTRY and
>> RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker since the
>> loop to call the handlers is inlined due to performance reasons. I would like
>> to add some sort of a callback mechanism which is invoked in
>> rtems_interrupt_handler_install() and rtems_interrupt_handler_remove()
>> operations (similar to the user extensions). There are some options to do this.
>>
>> 1. A new linker set with functions.
>>
>> 2. A new user extension, maybe a generic:
>>
>> void (*event)(rtems_extension_event event, void *arg);
>>
>> 3. An API to install/remove a specific callback for this purpose.
>>
>
> 4. Update or add a new API call to return the currently installed
> handler. This way interrupts can be chained.
This API already exists:
https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html#ga31d23275b676018c06e13c7bedc87983
The problem with this approach is that it doesn't wrap new handlers and if you remove a wrapped handler, then a memory leak or worse may happen.
>
>> I am in favour of 1. I also would like to hide it from the user for now.
>
> Does 1. allow runtime installing and then tracing of an interrupt? I know 3.
> would.
Yes, 1., 2., and 3. do the same, the difference is how you install the wrapper functionality and maybe how many you can install.
5. Use a weak function.
More information about the devel
mailing list