Re: Wrap Interrupt Handlers for Recording?
- Am 5. Sep 2019 um 7:25 schrieb Chris Johns chr...@rtems.org: > On 5/9/19 2:25 pm, Sebastian Huber wrote: >> - Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@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 () 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. > > Yes care needs to be taken with this approach. > >> >>> 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. > > It is difficult because you may want to trace one of a number of interrupt > sources or you may want to trigger tracing of another event due to system > issues. For this complex scenario the proposed approach is not the right tool. To trace individual interrupts, you can wrap the specific interrupt handler and do your complex stuff. > >> >> 5. Use a weak function. >> > > Would this mean the overhead of the weak function happens all the time? I mean weak functions which are called during interrupt handler install/remove. The interrupt dispatching should remain as is with absolutely no overhead if recording is disabled. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Wrap Interrupt Handlers for Recording?
On 5/9/19 2:25 pm, Sebastian Huber wrote: > - Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@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 () 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. Yes care needs to be taken with this approach. > >> >>> 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. It is difficult because you may want to trace one of a number of interrupt sources or you may want to trigger tracing of another event due to system issues. > > 5. Use a weak function. > Would this mean the overhead of the weak function happens all the time? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Wrap Interrupt Handlers for Recording?
- Am 4. Sep 2019 um 23:41 schrieb Chris Johns chr...@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 () 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Wrap Interrupt Handlers for Recording?
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 () 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. > 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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Wrap Interrupt Handlers for Recording?
Hello, I would like to wrap calls to interrupt handlers which use the generic interrupt framework () 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. I am in favour of 1. I also would like to hide it from the user for now. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
