SHREE LEARNING ACADEMY

The operating system not only manages CPU and memory but also has more resources to manage. Input Output devices interact more with the operating system. We can divide the input output devices into 2 parts, one is their controller and the other is the device itself. It takes commands from the operating system and then completes them like reading some data from a device.

In the whole situation, the interface of the control of device is complicated. So it is the responsibility of the controller to give a slightly less complicated interface to the operating system. Like the disk controller can accept a command read sector 25,112 from disk 3. Now the controller has to convert this linear sector number to the format of cylinder, sector and head. This conversion can be a bit complicated because there are more sectors in the outer cylinders compared to the inner cylinders and there may be some bad sectors which have been remapped in other sectors. Then the controller will also have to see which cylinder and disk arm is in that region and how much movement will have to be done in that direction so that the sector we want to read should be brought under it. When the sector is under it, after that it can start reading the data.

Every controller is different, so different software is required which can control the controller. The software who talks to the controller is called as the device driver. Every controller manufacturer also has to provide a driver for each operating system, which they support. That is why a printer comes with its drivers which are based on different operating systems. for example OS X, Windows 10, Windows 7, Linux etc.

For us to use the drivers, we have to put them inside the OS so that they can run in kernel mode. By the way, drivers can also run outside of kernel and nowadays some operating systems are also supporting this thing such as Windows and Linux. All drivers in the MINIX 3 operating system run in the user space. But still many drivers run in the kernel itself.

Each controller has some registers that help it to communicate. For example, a disk controller has some registers so that it can store disk address, memory address, sector’s count, and read or write command. The driver gets a command to start the controller from the operating system which he translates into the language of the controller and then stores it in the registers of that device. We call the collection of all device registers as input output port space, which we will see in the upcoming chapters.

We can carry out the Input Output in 3 ways

Polling/Busy waiting

The simplest method is in which a user program issues a system call. Kernel converts this system call to a procedure call for that particular driver. Now the driver starts the input output and then continuously poll the device. Device polling means that it continuously asks the device whether its work is done or not. When the input output is completed then the driver returns the data wherever it is to be sent, then the operating system returns control to the caller. Caller is the user program who made the system call. We call this method busy waiting and the biggest disadvantage of this is that it keeps the CPU constantly busy polling the device until the work is completed.

Interrupt

The second method is the one in which the driver starts the device and tells it to interrupt when its work is complete, interrupts means that the device tells the driver on its own that its work is done, due to this, the driver does not have to constantly poll the device. The driver returns as soon as the work is allotted and the operating system blocks the caller if needed and then starts doing its other tasks. When the controller's work is finished, it generates an interrupt and gives the signal that the work is finished.

In the world of the operating system, interrupts are a very important concept. So let's see it in a little more detail. We see 3 steps in the figure below. In step 1, the driver tells the controller what work is to be done with the help of device registers and then the controller starts the device. In step 2, when the controller finishes its work, then it signals the interrupt controller chip with the help of a particular bus line. In step 3 if the interrupt controller is ready to accept the interrupt then it inserts a pin to tell the CPU. in step 4 interrupt controller puts the number of that device in the bus of the CPU so that the CPU knows which device’s work has been completed.

Then when the CPU decides to get interrupts, it pushes the program counter and PSW inside the stack and switches the CPU in kernel mode. We use the device number as an index so that we can find the address of the interrupt handler from memory which is used for that device. We call this part of the memory as the interrupt vector. The interrupt handler is the part of a driver that is used to handle the interrupting device. When the interrupt handler starts, it removes the program counter and PSW from the stack and saves them and tries to know the status of the device. When the handler's work is finished, then it returns to the first instruction which is yet to be executed of the user program which was running the earlier

Direct Memory Access

The third way to do Input output is, in which we use a special hardware. The name of that hardware chip is DMA i.e. Direct Memory Access. This chip can control the data which is being transferred between memory and any controller without disturbing the CPU. The CPU sets the DMA, telling how many bytes to transfer, what the device and memory addresses are, and what will be the direction. When DMA’s work gets completed it generates an interrupt after which it is handled in the same way as we did earlier. We will discuss about DMA and input output hardware in further chapters in more detail.