Interrupts, firmware, and I/O 21 Step 5-Interrupt handler The IDT is a table where the OS (or a driver) registers handlers for different interrupts that may occur. Each entry points to a handler function for a specific interrupt. The handler function for a network card would typically be registered and handled by a driver for that card. Note The IDT is not stored on the CPU as it might seem in Figure 1. 3. It's located in a fixed and known location in the main memory. The CPU only holds a pointer to the table in one of its registers. Step 6-Writing the data This is a step that might vary a lot depending on the CPU and the firmware on the network card. If the network card and the CPU support direct memory access (DMA ), which should be the standard on all modern systems today, the network card will write data directly to a set of buffers that the OS already has set up in the main memory. In such a system, the firmware on the network card might issue an interrupt when the data is written to memory. DMA is very efficient, since the CPU is only notified when the data is already in memory. On older systems, the CPU needed to devote resources to handle the data transfer from the network card. The direct memory access controller ( DMAC ) is added to the diagram since in such a system, it would control the access to memory. It's not part of the CPU as indicated in the previous diagram. We're deep enough in the rabbit hole now, and exactly where the different parts of a system are is not really important to us right now, so let's move on. Step 7-The driver The driver would normally handle the communication between the OS and the network card. At some point, the buffers are filled and the network card issues an interrupt. The CPU then jumps to the handler of that interrupt. The interrupt handler for this exact type of interrupt is registered by the driver, so it's actually the driver that handles this event and, in turn, informs the kernel that the data is ready to be read. Step 8-Reading the data Depending on whether we chose method 1, 2, or 3, the OS will do as follows: Wake our thread Return Ready on the next poll Wake the thread and return a Read event for the handler we registered