traps and interrupts

sancho1980 · Post by **sancho1980** » Fri Aug 10, 2007 9:10 am

hi

this site [wiki]http://www.osdev.org/wiki/IDT[/wiki]

sasys:

Trap and Interrupt gates are similar, and their descriptors are structurally the same, they differ only in the "type" field. The difference is that for interrupt gates, interrupts are automatically disabled upon entry and reenabled upon IRET which restores the saved EFLAGS.

My question: how do I know if for a given handler it is appropriate to use a trap or an interrupt descriptor? Shouldnt interrupts ALWAYS be disabled?

Thanks

Martin

inflater · Post by **inflater** » Fri Aug 10, 2007 9:17 am

Interrupts always disabled? I think you mean hw interrupts, right?
If yes, well... if it's interrupt from 0x0-0x12, then yes (these are usually CPU exceptions).

But like if its 0x30 and you've got an custom interrupt handler for it, like your OS main functions (DOS = 0x21, Linux = 0x80), STI should be right before your OS main interrupt will try to access hardware (like: if you got a keyboard driver, and INT 0x30 along with AX=0100h or something like that [it can be everything] will wait for a keypress, missing STI before the, say "call waitforkeypress" will halt the system, because CPU willn't get any hardware interrupt from keyboard).

Traps? If thats name for the Screen-Of-Death handler, then yes, but only if your xSOD handler aren't working with hardware and waiting for hw interrupt (if it does, STI before the main call).

An example of xSOD handler that is waiting for a interrupt is, "Press ENTER to resume your work" or something like that, like hard disk interrupt, floppy interrupt etc.

Regards
inflater

sancho1980 · Post by **sancho1980** » Fri Aug 10, 2007 9:56 am

so what should i use for what?
suppose im writing an interrupt handler for the keyboard: trap or interrupt descriptor?

inflater · Post by **inflater** » Fri Aug 10, 2007 10:06 am

I think it doesnt really matter, i think these handlers are all the same (?). Use interrupt descriptor. Just make sure you dont give CLI to your keyboard handler

And, if you are (from the keyboard *driver*, not the keyboard IRQ handler) waiting for keypress, you can use HLT (this will halt the CPU until IRQ is triggered). Again make sure you dont give CLI to your keyboard handler or driver, CLI and HLT... will halt the system completely.

Summa summarum, "trap descriptor" for your SoD handler (when system will panic) and "interrupt descriptor" for everything else

Regards
inflater

Brendan · Post by **Brendan** » Fri Aug 10, 2007 10:43 am

Hi,

sancho1980 wrote:so what should i use for what?
suppose im writing an interrupt handler for the keyboard: trap or interrupt descriptor?

If you write your code carefully, then you should be able to leave interrupts enabled while you're executing the keyboard IRQ handler, and that way you can take advantage of the IRQ priorities and reduce interrupt latency for higher priority IRQs.

Sometimes this is a pain in the neck though - for e.g. your IRQ handler might be so quick that it doesn't effect interrupt latency much, or might have some sort of race condition that can be avoided if interrupts are disabled.

For some interrupt types, it's extremely difficult to make them interrupt safe. An example of this would be the double fault handler, where you can't really be sure that everything isn't messed up (and that an IRQ can be run without problems).

For some interrupts, you might even find that a mixture is best - for example, you might have some sort of tricky race condition at the start of the interrupt handler, so you use an interrupt gate but then restore EFLAGS after the tricky part and run the rest of the interrupt handler with interrupts enabled.

Mostly, just use interrupt traps (and leave interrupts enabled) unless you've got a reason not to...

Cheers,

Brendan