OSDev.org

I've been thinking about how to design my microkernel's interrupt handling scheme lately, and I ran across this conundrum.

It seems that many microkernels deal with interrupts by sending messages to threads in user-mode drivers rather than letting the drivers install ISRs. This keeps the kernel nice and simple, but I thought of a problem -- what if your kernel is running on a device with very few hardware IRQs? A smart phone, for example.

In a "macrokernel" or monolithic kernel (or a microkernel with kernel-mode drivers, although I hesitate to call that a microkernel), several ISRs could be registered for the same IRQ, and they would be called in sequence (Symbian OS does this, for example). Can this be done efficiently with a message-passing architecture and user-mode drivers? I doubt that it can, but maybe the more experienced among us know better...?

Hi,

Colonel Kernel wrote:Can this be done efficiently with a message-passing architecture and user-mode drivers? I doubt that it can, but maybe the more experienced among us know better...?

Regardless of what you do (for single_CPU), sending messages is always going to be less efficient than ISRs.

The best method I can think of (for single CPU) is to send the "IRQ notification" to one device driver at a time until one of them replies "It was me!". This would reduce the number of messages that need to be sent, especially if the OS sorts the list of device drivers in order of how often they are responsible for the IRQ.

For multi-CPU situations this can be extended such that for N CPUs N messages get sent to N device drivers at once. This way all CPUs can attempt to handle the same IRQ at the same time (better for interrupt latency).


Cheers,

Brendan

well, my approach is rather hybrid. I keep 'ISR handlers' in the kernel and 'hardworking' at userlevel. That means for instance that Clicker "microkernel" has a ISR handler in a module that reacts on mouse IRQs and perform basic task of decoding mouse packets. Once they're decoded, they're delivered as a message to the process that listen to the mouse device.

Same thing occurs with disk or network IRQs: data are retrieved at kernel (thus without incurring a process switch) and when done, a message notifies the requestor (e.g. the filesystem server or the network stack server) that requested operation is completed.