The Symbian OS (779886), страница 62
Текст из файла (страница 62)
The microkernel can thus be kept smalland fast. Another important feature of microkernel architecture is thatkernel functionality is deliberately simplified; more complex higherlevel behavior is moved out of the kernel onto the user side. Theprinciples parallel those of Reduced Instruction Set Computer (RISC)versus Complex Instruction Set Computer (CISC) processor design, withbroadly comparable arguments in favor.From microkernel architectures, the Symbian OS kernel borrows thefollowing features:• a message-passing framework for the benefit of user-side servers• networking and telephony stacks as user-side servers• file systems implemented as user-side servers.At the same time, for performance reasons Symbian OS compromiseson microkernel purity by allowing kernel extensions and including thedevice-driver framework in the kernel.
However, device drivers are notembedded in the kernel binary but follow the typical Symbian OS designpattern of being implemented as run-time loadable and unloadableplug-ins.From monolithic kernel architectures, the Symbian OS kernel borrowsthe following features:• kernel-side device drivers• scheduling policy implemented in the kernel.KERNEL ARCHITECTURE BLOCK287The test case for the success of the EKA2 kernel architecture is its abilityto support the real-time requirements of a GSM/wCDMA or CDMAphone-signaling stack ([Sales 2005, p.
778]). To do so requires thatreal-time guarantees can be given for key services, most importantlyinterrupt latencies, thread latencies and context switches. (‘Real-time’in this context means deterministic and bounded by a predictable andknown time; which is not quite the full definition.2 )The rationale for providing real-time support is two-fold. First, asphones become more complex and add more custom hardware, particularly to support multimedia functions, interrupt latencies becomeincreasingly critical to data throughput. Secondly, there is a specific goalto enable the Symbian OS nanokernel to operate as a true real-time operating system capable of hosting the baseband software. The baseband(phone software stack or ‘modem’) in a mobile phone requires real-timesupport in order to respond to the timing requirements of the signalingstack.Typical phone designs host the baseband stack on a real-time operatingsystem.
In a phone that also provides sophisticated application-sidesoftware including, for example, a full GUI, a second, application-centricoperating system is dedicated to providing the application support. The‘dual operating system’ design most commonly also implies a ‘dual core’two-processor design, in which dedicated baseband and application-sideprocessors host the respective operating systems and, in many cases, alsoown dedicated peripheral hardware including memory. Adding real-timecapability to Symbian OS is intended to enable ‘single operating system’,and hence ‘single core’, designs.The EKA2 architecture is based on a nanokernel which is designedto have sufficient functionality and the real-time properties required todirectly host a GSM, wCDMA or CDMA phone stack.
Phone stacks arenot yet commodity items and most have been written to interface toan existing real-time operating system (RTOS), whether bespoke or offthe shelf. The EKA2 nanokernel therefore supports a ‘personality’ layermechanism that enables an interface layer to be written between a givenRTOS and the software above it, while mapping calls into the interfaceto the underlying functionality of the nanokernel. This provides a way ofrunning a baseband stack directly on Symbian OS without having to firstport the stack. Writing a personality layer is a small task compared tothat of porting an existing phone stack or writing one from scratch to theSymbian OS nanokernel interface.3The kernel re-architecture had a secondary goal of improving themodularity of the kernel.
The EKA1 architecture includes an undesirable2See [Sales 2005, Chapter 17] for a detailed discussion of what real-time means andhow Symbian OS meets real-time requirements.3The task of creating a new phone stack, from design to full type approval, can take 10sto 100s of man-years of coding effort.288THE KERNEL SERVICES AND HARDWARE INTERFACE LAYERdegree of hardware dependency. Although at the lowest level of thekernel an EKA1 ‘variant’ DLL encapsulates many of the device-specifichardware dependencies, many ASSP-specific assumptions are containedin generic EKA1 kernel code, meaning that customization of kernel codeis still required to move to a new ASSP architecture (or, at the very least,the kernel needs to be recompiled).In the EKA2 architecture, all peripheral-related code (i.e.
code whichis ASSP-specific, but not specific to a particular licensee product) movedout of the kernel into a separate ASSP DLL. This provided better isolationof the kernel from the porting effort and enabled a more flexible approachto porting (since a licensee can choose how to structure the port betweenthe Variant and ASSP DLLs, to better support families of similar but notidentical devices; indeed, a licensee can even choose to dispense withthe ASSP DLL for a one-off port).ArchitectureThe project that led to the creation of EKA2, the ‘real-time’ kernel, had anumber of goals:• to enable the creation of single-core, single-operating-system productsin which baseband software, for example a GSM protocol stack,executed on the same processor as the application software, supportedby the same operating system• to improve average overall performance, as well as portability androbustness• better timer resolution, easier debugging, a better emulator (i.e.
a morefaithful ‘virtual’ port to Microsoft Windows), and general architecturalhousekeeping.EKA2 meets all of those goals. In particular, it is highly portable,running on X86 as well as many flavors of ARM processor architectures(ARM720/920/SA1/Xscale); on systems with different Memory Management Unit (MMU) styles, including no MMU;4 and on multiple ASSPs. Itsarchitecture (see Figure 11.6) is highly modular and carefully layered toisolate hardware dependencies.At the heart of the design, the nanokernel implements essential operating primitives and supports real-time guarantees for interrupt latencies,thread latencies and context-switching time bounds. The nanokernel isresponsible for the most basic thread scheduling, synchronization and4Realistically, the ‘no MMU’ option is intended as an aid to porting rather than asupported target architecture.
The security model, for example, depends on an MMU beingpresent to enforce memory protection between processes.KERNEL ARCHITECTURE BLOCK289User LibraryPrivilegeBoundaryGenericNanokernelMMKernelExtensionsArchitecturespecificVariantLDDsASSPPDDsFigure 11.6 Kernel architecture for EKA2timing functions. Extending the nanokernel, the kernel proper provideshigher-level operating-system services compatible with the EKA1 kernel.Both the nanokernel and the kernel are isolated from hardware dependencies by the Memory Model, ASSP, and Variant modules. The MemoryModel provides per-process address spaces and inter-process data transfer. The Variant represents the specific, ‘off-chip’ system hardware, whilethe ASSP represents the core silicon package.The device-driver model and extension mechanism control peripheraldevices and provide client interfaces.
(Extensions are statically linkeddevice drivers.)Kernel ResponsibilitiesThe Symbian OS Kernel implements the operating-system primitives ontop of which generic services are built by higher-level components (suchas the File Server and the User Library).
In particular, the kernel, includingits extension mechanisms, implements:• the thread and process models that provide the underlying basis forall code execution, including process creation and termination, codeloading, thread scheduling and the scheduling policy• memory management, including Direct Memory Access (DMA),which is an essential service underlying the process model• process protection and IPC mechanisms that guarantee process independence while allowing processes to cooperate; IPC is at the heart ofthe client–server model and policing of the platform security model• the device-driver model, which provides the device-level interface forsystem clients and applications• interrupt management, which is exclusively the responsibility of thekernel290THE KERNEL SERVICES AND HARDWARE INTERFACE LAYER• the power model, which provides an interface for higher-level clientsto manage and respond to the device power state• logical device drivers (LDD), which are implemented as plug-ins tothe device driver framework and provide a high-level device interface(i.e.
LDDs support classes of device, e.g. Ethernet ports)• physical device drivers (PDD), which are implemented as plug-ins toLDDs and provide the low-level interface to actual hardware presenton a device (for example, a specific Ethernet card)• various other high-level drivers (for example, accelerator plug-ins tothe Media Device Framework), which are not implemented as LDDs,operate at an equivalent level of abstraction.Kernel Executive CallsExecutive calls are the mechanism used to call into the kernel fromuser-side programs.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
