RE: [elysium-developers] IRQ handling

[Kasper V. L. <ve...@da...>]

> I'm not sure that IRQ sharing can be done securely w/o the
> kernel. There is no reason that processes that need the bind to
> IRQ's, need to trust each other. How can we make sure that a
> process will pass on an IRQ event to others? (without using the
> kernel, that is). But the line can be drawn later.

I agree - we need some *trusted* software to handle the sharing of IRQs, but
IMHO it should be implemented as a trusted server process on top of the
kernel.

> As for IRQ latency: For keyboards, latency is not a big issue.
> However for things like sound cards and network cards it is more
> important. But all OS's have bottom-halfs (therefore some
> latency) and w/o the kernel saving state I don't see another way
> of doing it.

A - low-latency - solution could be:
* a device generates IRQ 7
* the running process is interrupted by interrupt 0x27 which traps to the
kernel
* the kernel calls the IRQ handler for IRQ 7 using a task state segment
* when the handler is done (this might be time bounded) it returns using
iret
* the kernel is resumed by the iret and the kernel issues an EOI
* finally the kernel returns to the formerly running process

This is merely a suggestion - comments?

/Kasper