Linked by Hadrien Grasland on Sun 27th Feb 2011 12:06 UTC
Hardware, Embedded Systems 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.
Permalink for comment 464503
To read all comments associated with this story, please click here.
RE[3]: General Notes
by Anachronda on Tue 1st Mar 2011 22:52 UTC in reply to "RE[2]: General Notes"
Anachronda
Member since:
2007-04-18

I'm used to micro-kernels, where drivers run in user-space and the IRQ overhead itself (and therefore the potential risk of a second IRQ) is nothing compared to the cost of a (potentially unnecessary) task switch.


What happens if two devices request an interrupt on the same IRQ at the same time? I imagine it goes something like this:

- ISR takes interrupt, finds first driver attached to this interrupt, and sends a message to it. Interrupt is disabled until driver gets a chance to run.
- Microkernel eventually schedules driver, which processes interrupt request and re-enables interrupts from the slot.
- ISR takes interrupt from second device, which has been plaintively waving its hand the whole time, finds appropriate driver, and sense message to it. Interrupt is disabled until driver gets a chance to run.
- Microkernel eventually schedules driver, which processes interrupt request and re-enables interrupts from slot.

For monolithic kernels where performance is considered far more important than protection/security; the fastest way is to trash the kernel's code with random data as soon as any IRQ occurs. It's guaranteed to be faster than waiting for any number of arbitrary drivers to trash the kernel... :-)


Have you been looking at my code?

Reply Parent Score: 1