This is a situation where I need the help of you OSnews readers who are experienced with low-level development on ARM, SPARC, PowerPC, MIPS, and other hardware architectures we have on computers nowadays. The issue is that I’m currently designing the part of my hobby kernel which takes care of interrupts. Although I mostly work on x86 at the moment, I’d like to keep this code portable to other hardware architectures in the future. To do that, I have to know how interrupt handling works on as much HW architectures as possible.
What I’m interested in is every process which OS developers have control on and/or must take into account between the moment where some piece of hardware connected to the computer’s motherboard emits an interrupt signal and the moment where the CPU is done switching to the interrupt handling code. As an example, on x86, the legacy PIC would fit in that category, and the interrupt/exception vector mechanism would also fit.
If there’s no standard way to do something, please mention the way(s) it’s *usually* done.
The interrupt handling model which I’m currently checking for portability is:
Hardware emits an interrupt signal
On its way, the signal optionally encounters one or more PICs which either stop it or direct it to one of the CPU’s interrupt pins (this means that PIC drivers are necessary on architectures which have one, but that they may be written separately)
The CPU reacts to the signal on its interrupt pin by fetching a “vector”, noticeable containing the memory address of the interrupt handler associated to that pin, doing some arch-specific tricks, and executing code at said address
Thanks in advance for your answers !
I remember on the Apple II, the keyboard would write the current key at a predetermined address, and the “OS” would poll that address to know keydown events and such.
Not sure if it’s useful to you though