Re: [elysium-developers] IRQ handling

[Adam L. <ag...@li...>]

On Tue, Feb 08, 2000 at 10:42:49AM +0100, Kasper Verdich Lund wrote:
> > 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.

Ah, ok. Fair enough

> 
> > 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

So in this case the kernel saves state?

> * when the handler is done (this might be time bounded) it returns using
> iret

Erm, no. The kernel is calling (thus it's an upcall into userland), therefore wouldn't the process return w/ a simple ret?

> * the kernel is resumed by the iret and the kernel issues an EOI

And the kernel would return w/ iret.

> * finally the kernel returns to the formerly running process

This sounds good.

AGL