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...?
Chained interrupts without ISRs
-
Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Chained interrupts without ISRs
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Re:Chained interrupts without ISRs
Hi,
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
Regardless of what you do (for single_CPU), sending messages is always going to be less efficient than ISRs.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...?
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Chained interrupts without ISRs
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.
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.