Concepts with Symbian OS (Symbian Books), страница 13

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. (Usually, if it is not serviced in this time, some event is lostor performance is degraded seriously.) The interrupt execution time isthe time required to service the interrupt. Interrupts with a short interruptlatency time must have a short interrupt service time.Interrupts are serviced in a kernel by an interrupt service routine (ISR).There are many ISRs (because there are many types of interrupt) and onlya few need to be recognized by the kernel at any given time.

Therefore,most kernel designs maintain a vector table that contains the interrupt anda pointer to its ISR. This table is finite and is coordinated with the numberof possible interrupt sources. When an interrupt occurs, the address ofthe ISR is looked up in the vector table and that ISR is called.It is important to note that, while an ISR runs on the kernel side ofan operating system, the context – or state – of the system cannot beassumed. An interrupt can occur at any time and the system could be inany state when the kernel is interrupted. This inability to access any kindof context information restricts what can be done in an ISR.Interrupts are typically implemented by an operating in several phases:1.The preamble phase saves the context of the executing process andprepares to execute the ISR.2.The second phase determines which code to execute on behalf of theinterrupt request (it dispatches the interrupt).

This is either a built-inroutine (in the case of a system class) or an external piece of code.3.The third phase is the execution of the system call or ISR code,handled by privileged-mode code. Typically, this phase is itselfinterruptible.4.The last phase implements the closure of the process (the ‘postamble’phase). This typically amounts to a reversal of the preparatory phase:56KERNEL STRUCTUREthe context is switched back to the interrupted process or storage isrestored and execution resumes where it left off.3.4 Completing the Kernel Design in Symbian OSThe smartphone platform is a unique one. It requires many real-timeservices, but also must provide an environment that is similar to a desktopsystem in its richness.

In order to respond to both of these requirements,the Symbian OS kernel has a more complicated structure than the oneoutlined earlier in this chapter. In this section, we expand our look atthe structure of the Symbian OS kernel by fleshing out a complete kernelstructure.The kernel structure is shown in Figure 3.2. It is organized in relationship to how system calls are made, that is, the path a user-mode programmust travel to execute privileged code in the kernel.The Symbian OS model starts by working with the peripheral hardware. Several kernel components communicate directly with a smartphone’s hardware.• Device drivers, the interface for program code to work with devices(see Chapter 2), are split into two pieces in Symbian OS: the physical device driver (PDD) interfaces directly with the hardware andUser threadFile serverEFSRVUser modeHALPersonality layerRTOSPrivilegedUser library EUSERMicrokernel serversNanokernelSymbian OS kernelMemory modelASSPPeripheral hardwareFigure 3.2 Structure of the Symbian OS kernelLDDPDDExtensionCOMPLETING THE KERNEL DESIGN IN SYMBIAN OS57the logical device driver (LDD) presents an interface to upper layersof software.

In addition, the kernel can interact directly with hardware through the application-specific standard product (ASSP), whichimplements a number of components through a standard interface (soa specific driver is not needed). Finally, real-time components of theoperating system – those specifically involved in phone calls – canalso interact directly with the phone hardware when they run in aspecial mode (called the ‘personality layer’).• The memory model used by the operating system is a model of howmemory is organized on a device and how the operating system workswith it. We deal with memory management and memory models inChapter 7. Several memory models are possible in Symbian OS andthese are implemented by the Symbian OS kernel.• The Symbian OS kernel relies on the nanokernel, but is separatefrom the real-time portions of the operating system.