kernel software trap handling

Question

I'm reading a book on Windows Internals and there's something I don't understand:

"The kernel handles software interrupts either as part of hardware interrupt handling or synchronously when a thread invokes kernel functions related to the software interrupt."

So does this mean that software interrupts or exceptions will only be handled under these conditions:

a. When the kernel is executing a function from said thread related to the software exception(trap) b. when it is already handling a hardware trap

Is my understanding of this correct?

The next bit:

"In most cases, the kernel installs front-end trap handling functions that perform general trap handling tasks before and after transferring control to other functions that field the trap."

I don't quite understand what it means by 'front-end trap handling functions' and 'field the trap'?

Can anyone help me?

Answer 1

To me, it seems to be saying that software interrupts are handled either A) in the same part of kernel code as hardware interrupts, or B) the kernel doesn't do anything at the moment when the software interrupt occurs, but will remember that the interrupt occurred, and when a function related to the software interrupt is called, will handle the interrupt then.

Windows has something called "Deferred Procedure Call" (DPC) where the bulk of interrupt processing is deferred until a convenient time. It does this because x86 CPU's only have one IRQ line that is multiplexed by an external PIC or APIC. When an IRQ is triggered, the CPU automatically disables IRQs until the interrupt service routine reenables them. But since there is only one IRQ line, that means when IRQs are disabled, that means all IRQs are disabled. x86 architecture has a lot of devices using IRQs so that means, really, that the system (or at least that particular CPU) is sort of held hostage during the time IRQs are disabled. Thus, the DPC mechanism exists to ensure that IRQs are turned off for the least time necessary. The ideal thing is for the ISR to do the absolute minimum processing necessary before reenabling IRQs and shift the rest of the work to a DPC.

I could be wrong, but I think software interrupts disable IRQs automatically as well. So even though a software interrupt doesn't have I/O to service, it's still causing the system/single CPU to not be able service other interrupts until the interrupt handler reenables them.

System calls using the assembly language INT instruction are software interrupts (unless Windows uses a different method now like Linux with it's linux-gate.so trick), as well as CPU exceptions including page faults, divide by zero,

So all interrupts are handled asychronously in Windows and any operating system really, I think, for the above reasons. I'm not a kernel expert or anything so just take the above as some insight.

Answer 2

This smells like homework, but I'll take a stab at it.

What it sounds like to me is it is saying that software interrupts (which are not the same as exceptions, perhaps!) at non-deterministic times. Basically, the OS wants to be efficient, and may handle them as part of another interrupt (hardware it seems) or when you enter kernel space (say, make a kernel request.)

As for the front-end trap handling, that's more or less saying that the kernel gets a shot before and after each trap that is handled. For instance, some are not able to be passed on to user code no matter how hard you try. The kernel just handles it and never lets user code touch it. Others might be as simple as setting up a different stack to handle the interrupt, then letting user code take a stab at it. If none of the user-level code handles it, then it will eventually take some default action.