Concepts with Symbian OS (779878), страница 6
Текст из файла (страница 6)
A Unix operating system builds device software (calleddrivers) into its model of files; the ‘open’ system call executes a devicedriver if the user is opening a device for access. Microsoft Windowscreates an API for each device – usually layers of APIs for each device.Windows has some of the ideas of Unix; it uses the nomenclature offiles to address device ports. But it also designs the access to devicesthrough unique APIs, not file I/O mechanisms.
By contrast, consider theapproach that Symbian OS takes to communication. In Symbian OS,servers are used to allow access to communication resources. While aSymbian OS user would still use an ‘open’ call (again using the Unixfile nomenclature) to gain access to a serial port, she would first have toconnect to the server that provides access to that port before she couldopen the port.In all models, concepts of abstraction and modularity are preserved.Actual implementations are not specified; the abstraction of the conceptual model is the important part at this stage. Much research and opinionhas been dedicated to the question of which model is best; both modelshave held up well under such scrutiny.COMPUTER STRUCTURES19The evolution of operating systems is usually spurred by changes inhardware and models that address these changes.
The roots of SymbianOS give a good example of this evolution. As we discussed in Chapter 1,Symbian OS finds its roots in EPOC, an operating system developedfor handheld computers.1 Mobile phones were a burgeoning technology and EPOC’s designers wanted to address that technology. EPOC,however, had no models to address telephony and therefore did notextend well to phone-based devices. EPOC evolved into Symbian OS toaddress mobile phones. As evidence of this evolution, one can spot muchcode in Symbian OS that has been derived from EPOC.
New modelsaddressing new technology had to be developed, naturally, and one cansee how new hardware and new technology drove operating systemdevelopment.All Operating Systems EvolveAll operating systems evolve. Some go extinct; some survive. There aremany references for operating system evolution. Check outwww.levenez.com/unix for a ‘genealogical’ look at the Unix operating system. The evolution of Microsoft Windows is documented byMicrosoft at www.microsoft.com/windows/WinHistoryIntro.mspx.The evolution of operating systems that run on Apple computerscan be found at www.kernelthread.com/mac/oshistory.
Evolution ofMS-DOS, the Microsoft operating system built for early PCs, continued until Microsoft Windows arrived. MS-DOS formed a foundationfor Microsoft Windows until Microsoft Windows 2000, but was thenrelegated to extinction.2.2 Computer StructuresAs we consider how operating systems address computer systems, weshould first outline what structures those systems are built from and how1Of course, you can think of the mobile phones on which Symbian OS runs as handheldcomputers. By definition, mobile phones are indeed handheld computers. However, wedistinguish handheld computers from mobile phones by defining handheld computers asa generic term describing computers that do not use telephony. Mobile phones are, then,handheld computers that use telephony.20THE CHARACTER OF OPERATING SYSTEMSthey are used.
The character of an operating system is determined, inpart, by the structures it has to address.System Structure and OperationKernel StructuresThe core programs and data of an operating system together comprisethe kernel. The kernel consists of the code that runs the operating systemon a CPU and the data – typically organized in tables – that are used tokeep track of how things are running on an operating system. The kernelis where the access to hardware is done and the kernel implements theoperating system’s design model.There are several types of kernel. Monolithic kernels are found onsome general-purpose computers; they implement all operating systemfunctions and hardware abstractions within the kernel itself.
This type ofkernel (see Figure 2.1) usually comprises large amounts of code and largeamounts of memory for system tables.Microkernels provide only a small set of system function and hardwaremodels. Much of the remaining functionality that might be found in amonolithic kernel is provided by server applications that run outside amicrokernel (see Figure 2.2). Servers in Symbian OS provide this type offunctionality.User softwareKernelHardwareFigure 2.1 Monolithic kernel structureCOMPUTER STRUCTURESUsersoftware21ServersKernelHardwareFigure 2.2Structure of a microkernelHybrid kernels are like microkernels, except that some of the externalapplication function is implemented in the kernel for performance reasons(see Figure 2.3).UsersoftwareServersKernelServersHardwareFigure 2.3Hybrid kernel structureLinux is typically considered a monolithic-kernel operating system.Most system functions are implemented in ‘kernel space’ (by the code22THE CHARACTER OF OPERATING SYSTEMSand within the memory of the kernel).
Symbian OS is implemented viaa microkernel. The example in Section 2.1 of defining and opening acommunication device serves well here. 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.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
