Distinguishing PIT fires from software interrupts

[gzaloprgm]

Hi, in my multitasking kernel I am using the PIT as a time base for sleeps (bad idea, I know).

The problem is that if a task keeps calling the scheduler (via int 32 for example), the time starts to drift.

How can I know if an interrupt was a real PIT fire instead of a software interrupt? Is there any way to ask the PIC if it just sent an interrupt?

Cheers,
Gzaloprgm

[Combuster]

How can I know if an interrupt was a real PIT fire instead of a software interrupt?

Do not use IRQ0 as a system interrupt, but reserve a system call for that

[Brendan]

Hi,

How can I know if an interrupt was a real PIT fire instead of a software interrupt? Is there any way to ask the PIC if it just sent an interrupt?

You can check if the corresponding flag in the PIC's "in service register" is set - if this flag isn't set then you know the PIC didn't send the IRQ.

However, a much better idea is to set the DPL in the IDT entry to zero for all IRQs and exceptions. In this case if any user-level code attempts to call the IRQ handler (or exception handler) using a software interrupt then it'll trigger a general protection fault (but if an genuine IRQ or exception occurs then CPU will still start the interrupt handler, without triggering a general protection fault).


Cheers,

Brendan