Date: Sun, 19 Dec 1999 10:09:11 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Gerald Hilderink <g DOT h DOT hilderink AT el DOT utwente DOT nl>
cc: djgpp AT delorie DOT com
Subject: Re: returning from interrupt with iret?
In-Reply-To: <83glet$2sf$1@dinkel.civ.utwente.nl>
Message-ID: <Pine.SUN.3.91.991219100847.27944Z-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sat, 18 Dec 1999, Gerald Hilderink wrote:

> I am writing a special embedded kernel that runs on micro-controllers, DSPs
> and also the i386 processor. For the i386 processor I use the _go32_dpmi_*
> functions in C for registering ISRs. This works fine. The kernel allows
> nested interrupts and for the last interrupt it may need to do a context
> switch (by swapping stack pointers) within an ISR and when its IRET is
> executed it should load the new Instruction Pointer for the new context.

This is one of the things that the DPMI specification disallows: you
cannot switch application's context from within a hardware interrupt
handler.

> This does not work with DPMI, because the *_iret_wrapper mechanism or so is
> using the stack as well. Therefore I want to add my own inline assembler
> IRET code. Unfortunately, I can not find the information I need to do this.
> Maybe other techniques can help me?

Can you explain why do you need to switch context in an interrupt
handler?  Can the context switch be delayed until the interrupt
handler returns?  If it can, you could use the signal support
mechanism to implement the task switch.