Concepts with Symbian OS (779878), страница 42
Текст из файла (страница 42)
Input and output are harderresources to manage, however, because of their variety in function andspeed. While the CPU of a computer remains the same, any number ofI/O devices can be connected and disconnected. Consider a mouse, aCD-ROM drive and a printer. These devices are all different in speedand in the way they are used, yet they must all be managed by the sameoperating system.We typically manage complexity by using abstraction. Throughout thisbook, we have emphasized how operating systems try to deal with therelevant details of something through a standard interface, while ignoringmuch of the complexity that is not relevant to management.
That is themethod used here: standard interfaces handled in a standard mannerallow I/O technology to expand and differentiate without forcing theoperating system to change at the same rapid pace. However, innovationaround I/O advances rapidly and standard interfaces are often outpacedby the needs of new devices – thus resulting in new ‘standard’ interfaces.This, too, must be managed and allowed to happen in a controlled setting.There are three components that are important to an operating system’smanagement of I/O. Device controllers on the hardware side are linkedto device drivers on the software side by buses (see Figure 9.1).Hardware Interface: Device ControllersA device controller is a hardware component that represents the hardwareinterface to the operating system. A controller has the ability to operatethe device to which it is attached.
A controller provides an interfacethat translates between the complex working of an I/O device and theoperating system.A controller is really a device in its own right. It is typically made up ofa processor, some memory and some microcode that enables it to processinteractions with an operating system. It is programmed to interact withthe operating system using standard interfaces and to translate the abstractinteraction it receives through its interfaces into specific operations thataccomplish on a device what the operating system is asking.
A controllercan operate a simple device, such as a serial device, or it can be in chargeof a complex system, such as storage media. The controller is responsibleI/O COMPONENTS199Operating systemDevice driverBusDevice controllerI/O deviceFigure 9.1Relationship between device drivers and device controllersfor performing tasks that the operating system requires, such as reading,writing, formatting or mapping bad sectors.Sometimes a controller is not directly connected to its device usingan I/O bus system such as USB or Firewire.
A controller must sometimescommunicate with many devices at once across an I/O bus connection. In all cases, a controller represents the hardware side of the I/Oabstraction.Software Interface: Device DriversThe software side of the I/O abstraction is a collection of device drivers. Adevice driver is a piece of software that interacts with the operating systemusing a standard interface and then interacts with device controllers,providing the software side of the translation between the operatingsystem and the device.Since devices are invented and evolve rapidly, supplying device driversthat work in each operating system is typically the responsibility of a200INPUT AND OUTPUThardware manufacturer.1 When a user attaches a device, that deviceusually comes with a driver that can be (or sometimes has already been)installed and can handle the new addition. When the operating systemneeds something done, it communicates with the device driver, whichcommunicates with the device controller, which, in turn, operates thedevice itself.Bus ConnectionsThe glue that holds device controllers to device drivers is an I/O bus.
Atthe hardware level, a bus is a set of wires that communicates data – bothusable data and control data – between connections. These physicalconnections tie the device driver to the device controller. At the softwarelevel, a bus is seen as a connector that allows messages, requests, andtransfer of data between the operating system and an I/O device.The communication between a driver and a controller happens according to a protocol.
Protocols are the language of request and service,providing methods to communicate that provide for accurate and errorcontrolled delivery of data. A protocol can be seen as an agreementbetween two parties: when one side does something, the other sideknows how to respond because both are abiding by a set of rules.The Small Computer Systems Interface (SCSI) bus in a computer systemis a good example here.
The SCSI bus is connected to several SCSI devicesat the same time. Each device has a SCSI controller that knows how touse the SCSI protocol to communicate with the SCSI device driver forthe operating system. This SCSI protocol is very complicated. The SCSIbus has a certain type of design that accommodates this complexity. Thisdesign differentiates it from the other buses in a computer system.It is interesting to note that, as with the SCSI example, some devicedrivers are tuned to the bus protocol rather than the device they arecontrolling.
In the SCSI example, all devices that connect to the SCSI buswork with the SCSI protocol. This means that device drivers can workwith that protocol too, rather than with each individual device. This canbe called a physical-device abstraction to logical device.1Sometimes the operating system provides the driver. This happens when standardsare clear and devices adhere to these standards. The USB mass storage driver of MicrosoftWindows is an example of this.I/O HARDWARE ISSUES2019.2 I/O Hardware IssuesA computer works with a large number of devices.
These generally fit intoseveral categories: storage devices, communication devices, interfacedevices and display devices. Devices that do not fit into these categoriestend to be specialized, such as data-gathering equipment or automobilemonitoring devices.
It is typical of a computer to control these devicesusing a standard interface and a set of generalized commands. Even withall this variety in hardware, just a few hardware concepts are needed tounderstand how hardware interacts with an operating system.General Device CommunicationAs discussed in Section 9.1, operating systems communicate with devicesthrough buses that connect components from device driver to devicecontroller. A general bus structure is shown in Figure 9.2.A device is connected to a computer system through a bus, but canbe connected to that bus in several ways. A device could be connectedUSB busDeviceScreen displayDeviceCPUDeviceCacheGraphicscontrollerBridge/memorycontrollerMemoryUSB controllerPCI BusIDE controllerExpansion businterfaceexpansion busDiskDiskCD-ROMParallel portSerial portFigure 9.2 Generic I/O bus structureKeyboard202INPUT AND OUTPUTdirectly by being plugged into the bus through a slot on the computer’smotherboard.
This is typical of desktop and server systems. Other devicesare connected through a cable, plugged into a port, or open receiver,on the computer. Others are connected wirelessly, for example, throughBluetooth technology. Sometimes devices can even be daisy-chainedtogether, when one device is connected to another, which is connectedto a third and so forth. Eventually one device in the chain must beconnected to a computer.Communication is initiated by a controller and destined for the operating system or by the operating system and destined for a device througha controller.
A simple way that these communications are passed on isthrough registers. Communication bits and bytes are passed through avariety of registers:• the status register contains a set of bits that are read by both thecomputer and the bus controller; the bits indicate states such aswhether a data transfer is completed or whether there has been adevice error• the control register is used to control the data exchange process; whenit contains data, that data is in the form of a command which usuallyamounts to ‘read’ or ‘status’, but bits can also be set to indicate howdata is to be transferred• the data-in register is read by the operating system to get input datafrom devices• the data-out register is written to by the operating system to pass datato a device.Data registers are typically between one and four bytes long. Somedevice controllers can hold buffers full of data waiting to be sent throughthese registers to the operating system.
The registers are situated eitherin dedicated I/O space in the CPU or in the main memory. This lattersituation is called memory-mapped I/O. In this implementation, the CPUwrites or reads data to or from the dedicated address or range of addressesof the main memory space.Device controllers also send data to operating systems throughmemory-mapped I/O.
Memory-mapped I/O uses the register idea but,instead of registers, memory on the processor is used. When the CPUsends an I/O request, it uses standard registers to issue the request but thedata ends up in main memory.I/O HARDWARE ISSUES203These two methods are adequate for small amounts of data but, forlarger amounts of data, they require too much movement of data oncethe data has left the bus. The direct-memory access (DMA) approachallows the bus controller to access memory directly and to signal to theoperating system when the I/O operation is complete.
All I/O functionshappen through memory: from initiation of an I/O operation to the arrivalof data and the signaling of operation completion. DMA allows theoperating system to service other needs and only attend to data when itis signaled.DMA works with system resources and shares them with the CPU. Itaccesses main memory just as the processor does. Occasionally, DMAdata transfer takes over a resource – for data transfer over the bus, forexample, or for depositing data in memory. In these cases, the CPU cannotuse the resource while it is in use for DMA. This artifact of DMA is calledcycle stealing and it can slow down access to computer resources.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
