Smartphone Operating System (779883), страница 7
Текст из файла (страница 7)
The implementation of devicesand how they are accessed in Linux is built into the kernel. To change theimplementation, one would have to change kernel code and recompilethe entire kernel. In Symbian OS, devices are implemented by server – notkernel – functionality. To change the way communication devices areimplemented in Symbian OS, one would have to change the code tothe server and recompile it.
No changes would have to be made to themicrokernel itself.Most modern systems are based on hybrid kernels. The most effectivearguments against monolithic kernels are that small changes to the systemrequire changes to the entire kernel and that errors in the kernel can causean entire system to crash. Monolithic kernels are also larger and may notbe suitable for devices with limited memory or systems that make gooduse of virtual memory.
Hybrid systems work around these problems bypushing many kernel functions to servers and by taking extreme care tomake the functions in the kernel modular and abstract.Monolithic systems have implemented several features to help them bemore flexible. For example, Linux implements the use of modules, whichare code libraries loaded at run time that implement support features ofthe operating system. If the system Linux is running on has a USB port,Linux can load the USB module to drive the port. Note however, thatwhile this allows flexibility and implementation outside the kernel core,once a module has been loaded, its operation and data become part ofthe kernel, adding to its monolithic character.InterruptsModern computer systems are typically built from components whichcommunicate with each other over a bus structure (see Figure 2.4).Notice that each device in Figure 2.4 is connected to the system busthrough a controller.
These controllers are specific to each device andcommunicate with each other, sharing and competing for bus access.Controllers act as a liaison between devices and a communicationmedium.In this system, the CPU must be the primary controlling device.Hence, across the bus, there is a hierarchy of device priorities and away for devices to work with this priority system.
Device controllers cancommunicate with any device sharing the bus and their communicationcan be pre-empted by other devices with higher priority.COMPUTER STRUCTURES23CPUSystem busMemorycontrollerDiskcontrollerDisplaycontrollerKeypadcontrollerMemoryFigure 2.4Structure of a generic computer systemIn a bus-based system, it would be a waste of time to continuouslycheck or listen to the bus to see if any device is communicating. Imaginestopping to pick up and listen to the telephone every several seconds tosee if someone wants to talk to you. Instead, the bus system is drivenby interrupts. An interrupt is like the ringing of a telephone: it is anevent that is designed to get the attention of hardware, software or both.Normally, a device is intent on doing a specific task and does that taskuntil its attention is drawn away elsewhere – for example, it finishes itstask or has a problem.
The device can raise an interrupt to alert the CPU.When interrupted, the CPU records what it was doing and services theinterrupt, returning to its previous task when the interrupt service hasbeen completed.Device communication is thus designed around this interrupt mechanism. In fact, such communication is typically based on a system ofinterrupts. Interrupts are serviced by interrupt service routines (ISRs) viaa table of vectors. These vectors are addresses of ISR-handling functionsthat a device is directed to execute upon the receipt of an interrupt.
Sincethere are many different devices with many different ways to communicate, there are many interrupt vectors built into a system, with manydifferent interrupts to go with them. As with devices, interrupts havepriorities to organize them; during the handling of one interrupt, the ISRmay ignore lower-priority interrupts to prevent them from running duringthe handling of an interrupt.24THE CHARACTER OF OPERATING SYSTEMSOperating systems embrace this interrupt system. Operating systemsare interrupt-driven. They typically do very little on their own, but insteadwait for interrupts to drive them to do their varied tasks.
Operatingsystems have many services that can be used and many ways to usethese services, but only offer them in response to requests. So operatingsystems have their own system of ‘interrupt vectors’ and these ‘vectors’are implemented using system calls into software implementations. Uponreceipt of an interrupt, an operating system stops what it was doing,saving the spot for its return, and finds a software implementation toservice that interrupt. When the interrupt service routine has completed,the operating system returns to where it left off.Interrupts make a great notification system, but sometimes notificationsneed to be turned off or ignored.
This is facilitated in operating systemsby masking. This terminology comes from the idea of using a bitstring torepresent all possible interrupts. By constructing a second bitstring with1s representing the interrupts to be enabled, this second bitstring can beANDed with the bitstring of interrupts to produce only those interruptswhich are enabled and functioning. This operation of masking is used toturn interrupts on and off. (In other situations, where a mask of bits is notused, the operation is still called masking.) Turning interrupts off allowsthe operating system to handle higher-priority interrupts without beingdistracted by other – probably lower-priority – interrupts.This model of interrupt-driven operation is so useful that softwareinterrupts have been worked into operating systems just like hardwareinterrupts.
Software interrupts take several forms. There are interrupts thatare triggered when errors occur (for example, reading beyond the endof a file), interrupts that cause the operating system to do certain things(for example, when a system timer goes off), and interrupts that have noestablished service routines (these are usually set up and driven by specificsoftware applications). Interrupts can be sent explicitly (for example, Unixallows ‘signals’ to be sent to the operating system through special systemcalls) or they can be generated transparently by making function calls(many Symbian OS system calls generate software interrupts).Since operating systems are passive software systems, there must bea way to get them started listening for and servicing interrupts.
Thisis typically done by a bootstrap program in a fixed storage location.The computer’s hardware is designed to find this program and start itsexecution. The bootstrap program is usually quite small and is designedto locate and start a much larger program. This second program is theoperating system implementation. The bootstrap program is usually storedCOMPUTER STRUCTURES25in read-only memory (ROM) supplied with the computer system. Thesecond program, or the kernel, is the system that sets up the computingenvironment and waits for interrupts to occur.ProcessesThe programs that run on a computer also work with the interrupt system.In modern operating systems, several programs execute at once, sharingthe computing resources.
These concurrent programs are called processesonce they begin running on the CPU. Obviously, if a single process ranto completion before another began to operate, a computer would runextremely slowly. Instead, processes run at the same time and rely oninterrupts to stop their execution, returning control to the operatingsystem. The scheduler is the part of the operating system responsible fordeciding which process should next execute on the CPU.An operating system that allows multiple processes to run in thismanner is said to support multitasking.
Multitasking shares the CPUaccording to policies developed by the operating system designers andperhaps the operating system users. One such policy is the time periodfor which a program uses the CPU, called a time slice. Note that it almostcertainly takes more than a single time slice for a program to executeto completion, since the period of time is in the order of milliseconds.This means that there are several programs, each using the processor fora time slice and each suspended while the operating system allows otherprograms to share the processor. This procedure of moving processes intoand out of execution on the CPU is called a context switch; there is muchhousekeeping to be done during each switch that provides each programa context in which to run.Operating systems may also support multithreading.
Multithreadingis different from multitasking in that multiple threads of control executewithin the memory space of a single process. Multitasking refers toswitching between processes; multithreading occurs within a specificprocess. Threads provide for code execution in a lighter form than withprocesses. For example, context-switching between threads uses a similarconcept to that of switching between processes but is quicker sincecontext information about the memory space does not need to change.Device I/OA computer system without devices is not very useful. How an operatingsystem implements communication with a device is important for many26THE CHARACTER OF OPERATING SYSTEMSreasons – including the performance of the computer and the ease withwhich it is programmed. From the previous section, we already know thatdevice I/O is driven by interrupts, but exactly how those interrupts aregenerated and serviced determine how efficient the operating system is.The general sequence of servicing I/O requests is depicted in Figure 2.5.The request made by an application is fielded by the operating systemthrough one of its APIs.
The operating system uses the device driverspecific to the device being accessed and passes the request on to thehardware device (note that operating system interrupts are not neededto pass this data on). The hardware receives the request and servicesit, passing the results back up through the system. The device interruptsthe operating system through the device driver and the operating systemdelivers the results to the application.Notice that the scenario depicted in Figure 2.5 requires a lot ofwaiting. While the operating system is working with the application’srequest, the application is waiting for it to be completed.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
