Why set_vector()?

This is an excerpt from my GSOC 2025 proposal: ` set_vector() function has been identified as unsafe and is slated for removal across all architectures and Board Support Packages (BSPs) in RTEMS because: - Incompatible Function Pointers: It has been reported to cause warnings due to incompatible pointer types. - Ambiguous Implementation: The implementation of set_vector() varies across BSPs, leading to inconsistencies and potential misconfigurations. For instance, the RTEMS BSP and Driver Guide outlines how set_vector() is responsible for installing an interrupt vector and invokes support routines necessary to install an interrupt handler as either a "raw" or an RTEMS interrupt handler. ` Before delving into the reasons for its deprecation and implementation details, I will explore the fundamental role of set_vector(). What does set_vector() do? In an operating system, multiple programs share CPU time one after the other repeatedly called as context switching to provide an "illusion" of concurrency. For example, I am listening to music in my browser and trying to run a python script on Kaggle. I as a normal user is getting what I expect from the computer, i.e. two tasks happening at the same time. But the OS is switching CPU time between these applications called Processes to facilitate concurrency. All this while, something else is happening too. Music is playing, I am using Kaggle and trying to type my program. I am trying to use a hardware device to put characters onto the screen. Or I can say I am interrupting the normal switching between my music app and the Kaggle page to listen to what my hardware is trying to say. These events are called Interrupts. Interrupts can be broadly classified into:​ - Hardware Interrupts: Generated by hardware devices (e.g., keyboard input, mouse movement). - Software Interrupts: Initiated by programs to request system services.​ For simplicity, we'll focus on hardware interrupts in this discussion. What happens when a