OSDev.org

For my microkernel, I'm wondering how the kernel will be able to handle an IRQ. The kernel could send a message to the server that's in charge of the IRQ, but then how would the kernel know that the server is done? Also, after the server finished handling the IRQ, how will the interrupted thread be resumed?

My kernel will queue what I call a "Service Interrupt" onto the CPU. Before the kernel returns to thread context, it will check the CPU's service queue for any pending service interrupts, and runs these before running the thread.

My implementation is pretty involved, but it's really elegant, and should work well.

Hope this helps,
Sean

in my microkernel, I plan to have an interface (my kernel is highly component-oriented) the kernel itself implements an IIRQRegistrarInterface which takes an irq number and a IIRQHandler interface. at each irq, the IIRQHandler interface is called in the user-space program. The call is only scheduled to take place later(the receiver process will get the next time slot). then the iret instruction is called and the scheduler can go on happily. This system will be used for things like networking and stuff and not for things like the clock and keyboard, which will be pseudo-controlled by the kernel itself.

When I say pseudo-controlled I mean that you can register a handler but the kernel will take care of those interrupts. so a handler for a keyboard interrupt can only be used to know when a keyboard event occured and read that in.

deadmutex wrote:For my microkernel, I'm wondering how the kernel will be able to handle an IRQ. The kernel could send a message to the server that's in charge of the IRQ, but then how would the kernel know that the server is done?

You could let the server send a response message back to the kernel.

deadmutex wrote:Also, after the server finished handling the IRQ, how will the interrupted thread be resumed?

That's probably a topic concerning your scheduler. Some microkernels use thread priorities: A server which should handle interrupts has a rather high priority, so when an interrupt occurs (and the server receives a message) any currently running application thread is suspended (since application threads have lower priorities). When the server has finished servicing the interrupt and waits for the next one, lower priority threads can execute again.

If you really want to continue execution of that thread that was suspended earlier, it's getting a bit trickier. You could use queues in your scheduler. Whenever a thread is suspended because a higher priority thread suddenly becomes runnable (by receiving an interrupt message, f. ex.), the higher priority thread is inserted at the head of the queue (and thus scheduled first), while the suspended thread is the 2nd member in the queue. When the first stops execution, the formerly suspended thread is the first one for execution again.

Just an idea, maybe you could use it!

cheers Joe

JoeKayzA wrote: deadmutex wrote:
For my microkernel, I'm wondering how the kernel will be able to handle an IRQ. The kernel could send a message to the server that's in charge of the IRQ, but then how would the kernel know that the server is done?

You could let the server send a response message back to the kernel.

Yes, but if the server doesn't send a response message back to the kernel, wouldn't the server hog the cpu since the kernel has to send an EOI to the PICs?

Hi,

deadmutex wrote:You could let the server send a response message back to the kernel.

Yes, but if the server doesn't send a response message back to the kernel, wouldn't the server hog the cpu since the kernel has to send an EOI to the PICs?[/quote]

The server's thread will only get as much CPU time as the scheduler gives it (regardless of whether it's meant to be handling an IRQ or not). In general you'd want to place limits on how much CPU time any very high priority thread can consume (not necessarily just for threads used by IRQ handlers and device drivers).

If the server never replies then the kernel wouldn't send an EOI, which could prevent lower priority IRQs from being delivered to the CPU. Because of this you may want the kernel to monitor the IRQ handling, such that if a device driver doesn't respond quickly enough the kernel can attempt to recover (although this isn't necessarily easy - see this topic for more information).

Most OSs assume that interrupt service routines will respond (but most OSs don't use microkernels, and I wouldn't like to assume anything about user-level code).


Cheers,

Brendan

My microkernel uses a portal-like mechanism accessible to both user and kernel code. To handle an IRQ, it starts a pop-up thread that jumps through a portal to a handler in a user-level server.