Why is there a design difference between the way interrupts are serviced in case of linux and unix?

Question

In the book The Design of the Unix Operating System by Maurice it is mentioned that interrupts are serviced in the context of the running process as it doesn't spawns a new process to service interrupts.

So, in Unix a processor is doing exactly one of the two things: 1. In user-space, executing user code in a process 2. In kernel-space, in process context, executing on behalf of a specific process.

But, in many operating systems, including Linux, the interrupt handlers do not run in a process context. Instead, they run in a special interrupt context that is not associated with any process.This special context exists solely to let an interrupt handler quickly respond to an interrupt, and then exit.

So, in Linux a processor is doing exactly one of the three things: 1. In user-space, executing user code in a process 2. In kernel-space, in process context, executing on behalf of a specific process. 3. In kernel-space, in interrupt context, not associated with a process, handling an interrupt.

I want to understand why this change in design? Wouldn't it be faster if we service interrupts in the context of the running process?

Answer 1

It sounds like you are getting confused by terminology. I suspect that what you are calling "a special interrupt context" (certainly Linux documentation uses that term) is really just a shift to an interrupt stack made by the hardware. I suspect that Linux has its "interrupt context" simply to disable process-specific activities that should not be done in an interrupt.

I would be shocked if any operating system executed an actual process context switch during an interrupt (thus it is the process that was interrupted that is servicing the interrupt).