Smartphone Operating System (779883), страница 13
Текст из файла (страница 13)
A monolithickernel structure minimizes the loading of implementation layers. Muchof the functionality of device I/O, for example, is built into a monolithickernel. Response time is initially quicker because modules do not need tobe loaded. However, because many modules are loaded that are perhapsunneeded, memory requirements go up dramatically. Unix operatingsystems typically boot an active kernel that requires 10 MB to 60 MBat boot time. Microsoft Windows has a smaller requirement, but it istypically at least 8 MB of memory.Monolithic structures come preloaded with many of the implementations required to run an operating system.
The structure is very static,because support for various hardware is built in. On the other side of thesize spectrum, microkernel structures take up much less memory uponboot and their structure is more dynamic. Microkernels usually supporta ‘pluggable’ architecture with support for hardware that can be loadedas needed and ‘plugged into’ the kernel. Thus, microkernels are moreflexible – code to support new hardware can be loaded and plugged inany time – but monolithic structures are faster – they avoid the overheadof the pluggable interface).One way to enhance the performance of all types of active kernelcomponents is to give multithreaded implementations. Remember thatthe active part of the kernel is an executing process like the otherprocesses in the system.
Therefore, it can have multiple threads ofexecution running inside a single context. The benefit of multithreadingto kernel implementation is that each thread can execute a request forkernel service, resulting in multiple requests being serviced at the sametime. This is especially helpful when multithreading is implemented for52KERNEL STRUCTUREsystem modules – such as microkernel servers – and for user code. Whenall of these threads of control are capable of requesting kernel services,the kernel must be multithreaded to support them.Consider a user-mode application that requests a kernel-mode operation, for example, to load a set of data from a flash memory card. Asthe kernel is doing this, a phone call comes in and must be serviced.
Akernel with a single thread would have to select one of these requeststo work on and queue the other request for later service. The systemcould prioritize the requests by making the phone call (a real-timeoperation) more important and thereby making the user-mode requestwait. However, a multithreaded kernel could service both operations atthe same time, handling device interrupts with a thread separate fromuser-mode requests. While the CPU must still be shared between thesetwo requests, the end result is that service is faster because both operationsare in memory at the same time.Passive Kernel ComponentsPassive kernel components are those parts of the kernel that are notcontinually executing but are available for execution on behalf of servicerequests.
These components are present in the form of libraries anddynamically loaded modules that contain code that implements systemcalls and interrupt service routines. It is through these components thatuser-level code can get kernel-level tasks done on their behalf.These elements of the kernel are called passive because they do notexecute on their own.
They are spurred into execution when a systemcall is made or an interrupt is generated. They contain code that eitheroperates on its own in kernel mode or communicates with the activecomponents of the kernel. There are several examples of this type ofkernel component.• Device drivers are loaded dynamically by some kernel implementations when devices are used. In some operating systems – for example,Symbian OS – device drivers themselves are broken down into components that are loaded individually.
Symbian OS, for example, useslogical drivers that implement more abstract properties of a device(for example, operations such as read and write, on and off ) andphysical drivers that handle the specific implementation of the logicaloperations with specific devices.SYSTEM CALLS AND THE KERNEL53• Microkernel servers are usually run only when needed and terminatewhen their services are no longer required. Consider, for example,a smartphone whose user was exercising many applications that usemany different servers. As use continued, more servers would bestarted to service needs.
These servers might only be required for ashort time – to coordinate the use of Bluetooth, for example – and canafterwards be terminated. This keeps the tables of the kernel cleanerand emptier.• Passive behavior can sometimes be used to enhance performance.For some microkernel implementations, servers are started at boottime and run without shutting down. Because they only react torequests, they do not poll and are not actively executing at othertimes. Therefore, there is no cost to the CPU in leaving these serversrunning (although there is a memory cost because they consumememory resources permanently).
Symbian OS implements servers inthis manner.• Situations where the type of information can change dramaticallyoften require dynamic modules. For example, wireless messages fora smartphone are of very different types. Diverse message types arehandled by dynamically loaded libraries. In Symbian OS, these areknown as message type modules, or MTMs. There are special MTMsfor email messages and SMS messages.
There are many abstractionsthat are implemented as passive kernel components.3.2 System Calls and the KernelWe have seen processes that run in user mode and how processes andlibraries can cause execution in kernel mode. The interface betweenthese two modes is provided by system calls. These are function callsthat cause requests to be made to the kernel and the kernel to execute onbehalf of those requests.System calls constitute an extra layer between applications and innerlayers of the kernel structure. This extra layer has several advantages: itprovides a layer of abstraction that makes programming easier, freeingusers from knowing low-level details about the system and hardware;it increases efficiency and security, because the kernel can coordinateaccess to hardware and protect processes from each other; it makes54KERNEL STRUCTUREprogramming code more portable, since the code works on any systemthat supports the same set of interfaces.System calls are implemented as software interrupts.
A system call istypically implemented with a type of hardware instruction that causes aspecial interrupt handler to be invoked. The implementation either identifies the system call with an index into a table maintained by the operatingsystem or causes a jump to specific handler code. In either case, the implementation causes the system to go into privileged-mode operation andimplement a preprogrammed system function. Obviously, there needs tobe many of these specially-handled operations; for example, the ARMprocessor reserves 24 bits to identify which system handler to invoke.It is important to point out that the use of kernel mode and user modeis enforced by the operating system as a way to protect resources.
Itis easy to think that you can perhaps manipulate a device better thanthe kernel can and that anyone could summon up operations in kernelmode. However, the kernel’s role is to coordinate access and it only has acertain number of operations that are done in kernel mode. Most systemsdo not allow application code to perform kernel-mode actions, that is,to execute the instruction necessary to turn on kernel mode. However,various systems enforce this in very different ways.That last point is especially true in Symbian OS. Since Symbian OSv9.1, Platform Security has implemented capabilities: any request to thekernel must be accompanied by the capability to make that request.This type of security makes sure that, while a user-mode program cannotsimply make the kernel do anything, even the fixed number of tasks inthe kernel are protected.
Security issues and operating system protectionare discussed in Chapter 14.3.3 Interrupt ImplementationAs we have mentioned before, an interrupt is a signal of some sort,typically generated by hardware, that is used to inform the kernel of somecondition that needs attention. Typical interrupts are asynchronous deviceI/O notifications and initiation of device changes (such as allocation ofmemory or user-initiated read or write).
Because interrupt service involvesa change in system resources, servicing an interrupt is a kernel-modeoperation.The servicing of an interrupt is much like a kernel request from userside code. The interrupt itself – the signal – can be seen as a request forINTERRUPT IMPLEMENTATION55service. There are two important differences, however, between interruptsand user requests.
Interrupts must have a high priority and the servicingof interrupts is defined by a routine in the kernel’s memory supplied bythe device doing the interrupting.Interrupts are typically designed to have some indication of priority.This is a recognition that some interrupts are more important that others.For example, an interrupt from a timer to force a context switch is probablymore important than an interrupt from a keyboard that a character hasbeen typed. A device’s interrupt priority is typically selected based ontwo criteria: its latency requirements and its interrupt execution time. Thelatency requirement is the maximum time within which an interrupt mustbe serviced.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
