What are software and hardware interrupts, and how are they processed?

Question

I am not sure if I understand the concept of hardware and software interrupts.

If I understand correctly, the purpose of a hardware interrupt is to get some attention of the CPU, part of implementing CPU multitasking.

1. Then what issues a hardware interrupt? Is it the hardware driver process?
2. If yes, where is the hardware driver process running? If it is running on the CPU, then it won't have to get attention of the CPU by hardware interrupt, right? So is it running elsewhere?
3. Does a hardware interrupt interrupt the CPU directly, or does it first contact the kernel process and the kernel process then contacts/interrupts the CPU?

---

On the other hand, I think the purpose of a software interrupt is for a process currently running on a CPU to request some resources.

1. What are the resources? Are they all in the form of running processes? For example, do CPU driver process and memory driver processes represent CPU and memory resources? Do the driver process of the I/O devices represent I/O resources? Are other running processes that the process would like to communicate with also resources?
2. If yes, does a software interrupt contact the processes (which represent the resources) indirectly via the kernel process? Is it right that unlike a hardware interrupt, a software interrupt never directly interrupts the CPU, but instead, it interrupts/contacts the kernel process?

Solution

A hardware interrupt is not really part of CPU multitasking, but may drive it.

1. Hardware interrupts are issued by hardware devices like disk, network cards, keyboards, clocks, etc. Each device or set of devices will have its own IRQ (Interrupt ReQuest) line. Based on the IRQ the CPU will dispatch the request to the appropriate hardware driver. (Hardware drivers are usually subroutines within the kernel rather than a separate process.)

2. The driver which handles the interrupt is run on the CPU. The CPU is interrupted from what it was doing to handle the interrupt, so nothing additional is required to get the CPU's attention. In multiprocessor systems, an interrupt will usually only interrupt one of the CPUs. (As a special cases mainframes have hardware channels which can deal with multiple interrupts without support from the main CPU.)

3. The hardware interrupt interrupts the CPU directly. This will cause the relevant code in the kernel process to be triggered. For processes that take some time to process, the interrupt code may allow itself to be interrupted by other hardware interrupts.

   In the case of timer interrupt, the kernel scheduler code may suspend the process that was running and allow another process to run. It is the presence of the scheduler code which enables multitasking.

Software interrupts are processed much like hardware interrupts. However, they can only be generated by processes which are currently running.

1. Typically software interrupts are requests for I/O (Input or Output). These will call kernel routines which will schedule the I/O to occur. For some devices the I/O will be done immediately, but disk I/O is usually queued and done at a later time. Depending on the I/O being done, the process may be suspended until the I/O completes, causing the kernel scheduler to select another process to run. I/O may occur between processes and the processing is usually scheduled in the same manner as disk I/O.

2. The software interrupt only talks to the kernel. It is the responsibility of the kernel to schedule any other processes which need to run. This could be another process at the end of a pipe. Some kernels permit some parts of a device driver to exist in user space, and the kernel will schedule this process to run when needed.

   It is correct that a software interrupt doesn't directly interrupt the CPU. Only code that is currently running code can generate a software interrupt. The interrupt is a request for the kernel to do something (usually I/O) for running process. A special software interrupt is a Yield call, which requests the kernel scheduler to check to see if some other process can run.

Response to comment:

1. For I/O requests, the kernel delegates the work to the appropriate kernel driver. The routine may queue the I/O for later processing (common for disk I/O), or execute it immediately if possible. The queue is handled by the driver, often when responding to hardware interrupts. When one I/O completes, the next item in the queue is sent to the device.

2. Yes, software interrupts avoid the hardware signalling step. The process generating the software request must be a currently running process, so they don't interrupt the CPU. However, they do interrupt the flow of the calling code.

   If hardware needs to get the CPU to do something, it causes the CPU to interrupt its attention to the code it is running. The CPU will push its current state on a stack so that it can later return to what it was doing. The interrupt could stop: a running program; the kernel code handling another interrupt; or the idle process.

Comments

[Tim]

Thanks! (1) In software interrupt, are I/O operations done by I/O device driver routine within the kernel process? (2) is it right that the path that software interrupt goes through is one step shorter than the path for hardware interrupt? In other words, for software interrupt: software program -> device driver routine within the kernel process; for hardware interrupt: hardware -> CPU -> device driver routine within the kernel process?

[Tim]

Thanks! Is it right that hardware interupt cause the CPU to push its current state on a stack so that the hardware driver can run on the CPU and later pop back the interrupted process on CPU? Is software interrupt also cause the process running on the CPU to be pushed into a stack so that the requested service can be run on the CPU?

[BillThor]

Either interrupt will cause the state to be pushed on the stack. This allows the system to reload the state when it is done with the interrupt.

[Tim]

Thanks! if the requested service will not run on the CPU such as IO operations that are run on the IO devices instead of CPU, and the requesting process can continue running without waiting the requested service to finish, will the requesting process still be put into a stack?

[BillThor]

Normally, I/O read is called synchronously and the process won't run until the I/O completes. For reads you almost always want this. Writes usually occur asynchronously allowing the process to continue running.

[Tim]

Are you saying for writing, the requesting process doesn't have to be put into a stack but can continue running on the CPU?

[BillThor]

The requesting process will be put on the stack, but the device drive will queue the write. The stack will then be popped and the requesting process can continue.

[Tim]

Why will the requesting process be put in the stack, given that "Writes usually occur asynchronously allowing the process to continue running"? Do you mean allowing the process to continue running after writes finishes asynchronously?

[BillThor]

The process is put on the stack while the driver is invoked and queues the I/O. Yes, the write process continues asynchronously after the call returns to the running process. The queue processing will mostly be handled during hardware interrupts for the device.

[Trismegistos]

You seem very knowledgable in this area. Can you explain more about IRQ? Is each IRQ single pin on the processor which is connected to given hardware e.g. pci-express? How many of them typical PC have?