GSoC Update: set_vector is gone!!!

Quick Recap In my last update, I discussed why it is required to clear and unmask an interrupt in SPARC boards. Building on that, I finished removing set_vector() in SPARC first but faced some issues. The thing is, the function I wrote, SPARC_Clear_and_unmask_interrupt(), is for CPUs. More specifically: - How does the hardware know that it sent out an interrupt and whether it was received by the OS? - If the OS has received the interrupt, then the hardware shouldn’t send the same IRQ (Interrupt Request) again. - The hardware should also know when an IRQ has been processed and the OS is ready for the next set of interrupts. Explanations While set_vector() seemed simple, it did two main things in one function, registering an interrupt handler for the given vector and clearing and unmasking a trap. But notice how I had to specify both the vector and a trap? Each interrupt can be tagged to a vector; in simpler terms, each interrupt needs a unique ID so it can be identified. All the vectors associated with an external interrupt source are traps. So, traps can be thought of as a subset of interrupt vectors, but to distinguish between traps and normal vectors, a trap table is created which associates each trap with a vector. Troubles I ran into big problems with this confusion. As a replacement for set_vector(), I chose rtems_interrupt_handler_install() instead of rtems_interrupt_catch(), and they don’t behave in the same way. This detail, which I was not aware of, led to many test failures. I could see the tests failing but didn’t understand where or why, so I had to write a separate tiny application that triggered termios interrupts (since I was working on the console). After days of searching, I found the problem was actually simple: I had to pass the vector number to rtems_interrupt_handler_install() rather than the trap number. Probably I could have found the mishap much earlier, but I wanted to dig up the issue on my own, without ChatGPT, and th