• The controller abstracts away some of the low level features of the device.
• For disks, the controller does error checking, buffering and handles interleaving of sectors. (Sectors are interleaved if the controller or CPU cannot handle the data rate and would otherwise have to wait a full revolution. I do not believe this is a concern with modern machines where the electronics have increased in speed faster than the devices.)
• For analog monitors (CRTs) the controller does a great deal. Analog video is far from a bunch of ones and zeros.
• Controllers are also called adaptors.
• Typically the interface the OS sees consists of some device registers located on the controller (address to access, read vs write, length, data value, etc).
• Memory-mapped I/O vs. I/O space. In memory mapped I/O the device registers are mapped into normal memory space. So you need to know that

  load 8888<--4
  

  tells the disk read the sector whose address you previously loaded into 8800. In the I/O space you used different instructions (not ordinary loads and stores) to do essentially the same thing.

Homework: 2

5.1.3: Direct Memory Access (DMA)

• The disk controller gets the desired data from the disk to its buffer
• For programmed I/O (PIO) the cpu then does loads and stores (or I/O instructions) to copy the data from the buffer to the desired memory location.
• With a DMA controller, the controller writes the memory without intervention of the CPU.
• Clearly DMA saves CPU work. But this might not be important if the CPU is limited by the memory or by system buses.
• Very important is that there is less data movement so the buses are used less and the entire operation takes less time.
• Since PIO is pure software it is easier to change, which is an advantage.
• DMA does need a number of bus transfers from the CPU to the controller to specify the DMA. So DMA is most effective for large transfers where the setup is amortized.
• Why have the buffer? Why not just go from the disk straight to the memory.
  Answer: Speed matching. The disk supplies data at a fixed rate, which might exceed the rate the memory can accept it. In particular the memory might be busy servicing a request from the processor or from another DMA controller.

Homework: 5

5.2: Principles of I/O Software

As with any large software system, good design and layering is important.

5.2.1: Goals of the I/O Software

Device independence

We want to have most of the OS, unaware of the characteristics of the specific devices attached to the system. Indeed we also want the OS to be largely unaware of the CPU type itself.

Due to this device independence programs are written to read and write generic devices and then at run time specific devices are assigned. Writing to a disk has differences from writing to a terminal, but Unix cp and DOS copy do not see these differences. Indeed, most of the OS, including the file system code, is unaware of whether the device is a floppy or hard disk.

Uniform naming

Recall that we discussed the value of the name space implemented by file systems. There is no dependence between the name of the file and the device on which it is stored. So a file called IAmStoredOnAHardDisk might well be stored on a floppy disk.

Error handling

1. Detection should be done as close to where the error occurred as possible before more damage is done (fault containment). This is not trivial.
   
   
2. Correction is sometimes easy, for example ECC memory does this automatically (but the OS wants to know about the error so that it can schedule replacement of the faulty chips before unrecoverable double errors occur).

   Other easy cases include successful retries for failed ethernet transmissions. In this example, while logging is appropriate, it is quite reasonable for no action to be taken.
   
   

3. Error reporting tends to be awful. The trouble is that the error occurs at a low level but by the time it is reported the context is lost. Unix/Linux in particular is horrible in this area.

Creating the illusion of synchronous I/O

• I/O must be asynchronous for performance. That is the OS cannot simply wait for an I/O to complete. Instead, it proceeds with other activities and responds to the notification when the I/O has finished.
  
  
• Users (mostly) want no part of this. The code sequence

  Read X
  Y <-- X+1
  Print Y
  

  should print a value one greater than that read. But if the assignment is performed before the read completes, the wrong value is assigned.
  
  
• Performance junkies sometimes do want the asynchrony so that they can have another portion of their program executed while the I/O is underway.

Sharable vs dedicated devices

For devices like printers and tape drives, only one user at a time is permitted. These are called serially reusable devices and are studied next chapter. Devices like disks and Ethernet ports can be shared by processes running concurrently.

Layering

Layers of abstraction as usual prove to be effective. Most systems are believed to use the following layers (but for many systems, the OS code is not available for inspection).

1. User level I/O routines
2. Device independent I/O software
3. Device drivers
4. Interrupt handlers

We give a bottom up explanation.

5.2.2: Interrupt Handlers

We discussed an interrupt handler before when studying page faults. Then it was called ``assembly language code''.

In the present case, we have a process blocked on I/O and the I/O event has just completed. So the goal is to make the process ready. Possible methods are.

• Releasing a semaphore on which the process is waiting
• Sending a message to the process.
• Inserting the process table entry onto the ready list.

5.2.3: Device Drivers

The portion of the OS that ``knows'' the characteristics of the controller.

The driver has two ``parts'' corresponding to its two access points. Recall the following figure from the beginning of the course.

1. Access by the main line OS with an I/O request.
2. Accessed by the interrupt handler when the I/O completes (this completion is signaled by an interrupt).

Tanenbaum describes the actions of the driver assuming it is implemented as a process (which he recommends). I give both that view point and the self-service paradigm in which the driver is invoked by the OS acting in behalf of a user process (more precisely the process shifts into kernel mode).

Driver as a process (Tanenbaum)

• The user issues an I/O request. The main line OS prepares a generic (e.g. read, not read using Buslogic BT-958 SCSI controller) request for the driver and the driver is awakened (perhaps a message is sent to the driver to do both jobs).
  1. The driver wakes up
     1. If the driver was idle (i.e., the controller is idle), the driver writes device registers on the controller ending with a command for the controller to begin the actual I/O.
     2. If the controller is busy (doing work the driver gave it), the driver simply queues the current request (the driver dequeues this below).
  2. The driver blocks waiting for an interrupt or for more requests.
• An interrupt arrives (i.e. an I/O has been completed)
  1. The driver informs the main line perhaps passing data and surely passing status (error, OK).
  2. Find next work item or block
     1. If the queue of requests is non-empty dequeue one and proceed as if just received a request from the main line.
     2. If queue is empty, the driver blocks waiting for an interrupt or a request from the main line.

Driver in a self-service paradigm

• The user issues an I/O request. The main line OS prepares a generic request for the driver and calls the driver.
  1. The driver is called
     1. If the driver was idle (i.e., the controller is idle), the driver writes device registers on the controller ending with a command for the controller to begin the actual I/O.
     2. If the controller is busy (doing work the driver gave it), the driver simply queues the current request (the driver dequeues this below).
  2. The driver returns to the main line
• An interrupt arrives (i.e. an I/O has been completed)
  1. The driver informs the main line perhaps passing data and surely passing status (error, OK).
  2. Find next work item or return
     1. If the queue of requests is non-empty dequeue one and proceed as if just received a request from the main line.
     2. If queue is empty, the driver returns to the main line.