views:

192

answers:

1

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?

A: 

Software interrupts are not traps but parts of hardware interrupt handling deferred out of hardware interrupt context. Example would be the TCP/IP stack - copying packets out of the NIC into the OS buffers is done/initiated from the hardware interrupt routine, but protocol processing (ethernet -> IP -> UDP/TCP) is deferred to a software interrupt. They are often called bottom halves in operating system literature (vs. top-halves that directly talk to the hardware.) This is done to reduce scope of hardware interrupt(s) being disabled and to reduce OS scheduling latency. As such they are usually invoked at the end of common trap/interrupt entry but after the interrupt(s) is/are re-enabled, and/or by a dedicated software interrupt kernel thread.

Nikolai N Fetissov
so the software interrupts occur because of a system call in a hardware interrupt context? But a system call in a user mode process, per what I've read, will also cause a software interrupt, which might be deferred in handling until a hardware interrupt is caused, or will be executed?
Tony
Data flows both ways - from hardware (interrupts) via kernel (soft interrupts, buffering) to userland (syscall like read), and back from userland (syscall like write) to kernel buffers, filling which might trigger soft interrupts to be scheduled (this time deferring out of process context), and eventually to hardware via DMA or IO ports/memory. The input path is just easier to explain :)
Nikolai N Fetissov