Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 17
Текст из файла (страница 17)
Onlythe run area can be accessed by user mode programs (plus the codechunks); the rest of memory can only be accessed in the CPU’s privilegedmode (and therefore only by the kernel, device drivers, and other selectedOEM components). This means that a user process does not have directaccess to the data of other processes. Furthermore, a user process cannotaccess hardware devices or CPU data structures such as the MMUpage table.The run area is sometimes referred to as a sandbox since it providesan isolated world for the process to run in.3.5.7 Performance in Switching ProcessesThe time it takes for an operating system to switch between processesis greater than the time needed to switch between two threads withinthe same process.
One reason is due to the need to relocate the processdata in the memory map, although using an MMU to remap virtual tophysical memory is much faster than copying the actual data from onearea of physical memory to another. Even in the case of using an MMU,however, there is a performance hit. The time penalty is not so muchthe MMU remapping operation itself, but has to do with the processorcache. If the processor cache stores information referenced by virtualaddresses as opposed to physical addresses, then a cache flush must bedone every time the MMU remaps the addresses.
This is because virtualaddresses have now changed and the cache does not have the correctdata to reflect this remap, since it stores the data by virtual addresses.This clearing and refilling of the cache causes a significant performancehit.
Switching between threads in the same process, however, is faster,since no memory areas need to be remapped.Note that with the ARMv6 architecture, the cache corresponds to physical memory instead of virtual, and the architecture contains optimizedprocess switching hardware that Symbian OS v9 can take advantage of.In this case, process switching time is significantly reduced.3.5.8Fixed ProcessesSome OS-level processes are switched to so often that the performanceimpact of remapping their process data areas (via the MMU) betweenthe home and run areas is not acceptable. An example is the file systemprocess. To get around this, Symbian OS has the concept of a fixedprocess, where the process data always stays in the home area, evenwhen the process is executing.Fixed processes are faster to switch to since the MMU tables are notmodified.
However, the cost of doing this is that there can be only oneTHE KERNEL77instance of the process running at a time and that, since the code imagepoints to the data directly, the data location (of sufficient size) must bereserved and fixed in the system.3.6 The KernelThe Symbian OS kernel consists of a set of executables and data fileswhich runs in the CPU’s privileged mode and provides basic systemmanagement and control. The kernel handles the creation and schedulingof threads and processes.
It also manages communication between threadsand processes with objects such as mutexes and semaphores, as well asmediating inter-process data transfers. In addition, the kernel manages allthe system memory, and acts as a gateway that provides access to devicehardware.This section covers some of the key highlights of the Symbian OSkernel. If you want to understand the kernel architecture in detail,Symbian OS Internals is an excellent source.3.6.1 Symbian OS Kernels: EKA2 and EKA1Symbian introduced EKA2 (short for EPOC Kernel Architecture 2) inSymbian OS starting at Symbian OS v8.1b; it is found in all Symbian OSv9-based phones (S60 3rd Edition and UIQ 3). EKA2 replaces the originalSymbian OS kernel, retrospectively known as EKA1.The motivation for creating EKA2 was to add features determined tobe important through years of experience in implementing EKA1-basedSymbian OS smartphones.
A significant improvement in EKA2 is theability for Symbian OS to run on single processor smartphones, whichis important for keeping down costs. This was achieved in EKA2 byimplementing real-time processing capability so that both embeddedradio software and applications can run on the same processor. I willdiscuss this more, later in this section. Other additions include easinghardware porting and device driver implementation, changes to allowthe software platform to be secured, along with numerous other changes.3.6.2 Kernel ArchitectureFigure 3.4 shows the kernel architecture. The kernel, device drivers,kernel extensions, ASSP (short for Application Specific Standard Product),and variant layers run in privileged mode and therefore have access to allmemory and hardware resources.Abstracting the hardwareKernel functionality depends on the underlying hardware on a device.For example, timers are needed for task scheduling and timer services.78SYMBIAN OS ARCHITECTUREApplicationseuser.dllPrivileged codeKernelNanokernel (EKA2 only)KernelextensionsDevicedriversASSP layerVariant layerSmartphone hardwareFigure 3.4KernelAnother example is the control of the MMU and flushing the cache.The methods of controlling these features vary with the specifics of thehardware and CPU.The kernel is divided in such a way that the bulk of the kernelcode is abstracted from the hardware (i.e., it is written so that thedetailed specifics of the hardware do not matter).
At the bottom ofFigure 3.4 (just above the hardware itself) are the ASSP and variantlayers. These layers abstract the underlying hardware from a softwareviewpoint.The ASSP abstracts hardware for a specific family of closely relateddevices, and the variant layer handles variations of particular deviceswithin those families. As part of developing Symbian OS smartphones,manufacturers implement the classes that make up these layers. Since thesoftware interface is common, the kernel is able to run unchanged on thishardware once the lower-layer classes are ported to that hardware.Although not shown in the diagram, there is also a CPU layer thatabstracts the capabilities of the particular CPU of the smartphone.Device drivers are used primarily to control specific hardware peripherals such as communications ports, radio modems, or external storagedevices.
The kernel implements the functions for user programs to load,and communicate with, device drivers.Kernel extensions are hardware-specific modules written by the OEM.They are more tightly integrated with the kernel than device drivers. Kernelextensions are implemented as DLLs and are detected and initialized atTHE KERNEL79boot time.
They are primarily used for optional components that neededto be started early (e.g., DMA controller, power manager, etc.).User libraryAbove the kernel in Figure 3.4 is euser.dll, which runs in user mode.This is a DLL that provides user-mode access to kernel functionality forapplications. Since the kernel runs in privileged mode, the functions ineuser.dll will switch the processor from user mode to kernel mode,then invoke the appropriate kernel function. Upon return, the mode isswitched back to user mode.The component that actually allows user software like euser.dll toinvoke the kernel is called the kernel executive. The executive consistsof a set of software interrupt handlers, which, when invoked, will switchthe CPU from user mode to privileged mode.
When a kernel functionis called from an application via euser.dll, a software interrupt (theSWI instruction on ARM) occurs that invokes the appropriate kernelfunction. In EKA1, some kernel calls had to be routed to a kernel serverinstead of being handled completely in the executive. The reason isthat the executive in EKA1 had some restrictions on accessing kernelobjects, thus requiring the commands to be done in the kernel server.However, in EKA2, this is not needed since it now can access kernelresources directly in the executive (as user threads now have a kernel-sidestack).Note that the user library contains more than just interrupts to invokethe executive – it also contains basic functions to do things such as stringand array manipulation.NanokernelAs shown is Figure 3.4, EKA2 has a nanokernel as part of its architecture.The nanokernel, which makes up just a small percentage of the overallkernel code, supplies basic services, such as simple supervisor modethreads, and the rest of the kernel expands on these services.
Thenanokernel also handles all the system interrupts initially and containsother mechanisms to ensure a predictable response time for softwarerunning on it, thus enabling real-time behavior in Symbian OS. Real-timeprocessing and the role of the nanokernel in EKA2 is discussed in the nextsection.3.6.3 Real-Time Processing in EKA2In a computer system it’s a given that in order for a piece of softwareto work right, all computations must be correct. Real-time systems addanother component to this – time.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
