Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (Symbian Books), страница 6

Class library methods that execute entirely user-side, such as mostmethods in the array and descriptor classes (descriptors are theSymbian OS version of strings)2. Access to kernel functions requiring the kernel to make privilegedaccesses on behalf of the user thread, such as checking the time orlocale settings3. Access to kernel functions requiring the kernel to manipulate its ownmemory on behalf of a user thread, such as process creation orloading a library.Every Symbian OS thread gains its access to kernel services through theEUSER library.

It is this interface that we have largely maintained betweenEKA1 and EKA2, resulting in minimal disruption to application authors.1.3.2.10 File serverThe file server is a user-mode server that allows user-mode threads tomanipulate drives, directories and files. Please turn to Chapter 9, The FileServer, for more details.1.3.2.11 Window serverThe window server is a user-mode server that shares the screen, keyboardand pointer between all Symbian OS applications. See Chapter 11, TheWindow Server, for more details.1.3.2.12 Software layeringWe can also consider the architecture of Symbian OS from a softwarelayering perspective, as shown in Figure 1.2.If you are familiar with EKA1, you will notice that the layering of EKA2is a little different.

Nonetheless, there are strong similarities, as we movedown from the most generic, independent layer, in which code is sharedbetween all platforms, to the most specific variant layer, in which codeis written for a particular ASIC on a particular development board or in aparticular mobile phone.We call the top four software layers ‘‘the kernel layer’’, and the bottomtwo, ‘‘the peripheral layer’’. These last form a key part of the boardsupport package that a phone manufacturer implements when portingSymbian OS to new hardware. This also comprises the bootstrap anddevice drivers and extensions.12INTRODUCING EKA2NKernNKernSymbian OS KernelIndependentMemory ModelPlatformMemory ModelModelMemory ModelSymbian OS KernelCPUASSP DLLASSPVariant DLLVariantFigure 1.2Kernel layeringThe independent layer makes up about 60% of the kernel sourcecode.

It provides the basic building blocks of the nanokernel and theSymbian OS kernel – nanothreads, threads, processes, chunks, clientserver and more. These base classes are derived in lower layers toprovide implementations for the particular hardware on which SymbianOS is running.The platform layer is concerned with executable images – whetherSymbian OS is running on the emulator or real hardware – hence itsalternative name of the image layer.

Only the memory model has codeat this level, and it provides two implementations, EPOC for devicehardware and WIN32 for the emulator.The model layer is all about the organization of per-process memory,and again only the memory model has code at this level. The memory model provides four different implementations – moving, multiple,direct and emulator. I will discuss these in more depth in Chapter 7,Memory Models.The CPU layer is for code that differs according to the processor thatSymbian OS is running on; this is where assembler code belongs. Thenanokernel, memory model and Symbian OS kernel all have code inthis layer. At the time of writing, Symbian provides three possible CPUlayers – X86 (a port to PC hardware), ARM (mobile phones) and Win32(for the emulator).The CPU layer of the memory model has code that is CPU- andMMU-specific, as well as specific to the type of memory model.

Thenanokernel’s CPU layer contains most of the knowledge of the core CPUarchitecture – how exceptions and interrupts are handled, which registersneed to be saved on a context switch and so on. A good proportion ofthe code in the CPU layer of the Symbian OS kernel is independent layerfunctionality that has been assembler-coded for improved performance.SYMBIAN OS DESIGN13The variant layer provides the hardware-specific implementation of thecontrol functions expected by the nanokernel and the Symbian OS kernel.As I mentioned earlier, the phone manufacturer can choose whether tosplit this layer into an ASSP and a variant when porting to new hardware.This variant layer can also provide hardware-specific implementationsof hardware abstraction layer (HAL) functions, although these may equallybe implemented in the kernel itself or in extensions.In Chapter 5, Kernel Services, I will explain what services each layerexposes to the other layers.1.3.3Design solutionsNow I’m going to talk about the design decisions that we took for EKA2,and how they helped us to achieve the goals that we had set ourselves.1.3.3.1 Multi-threaded preemptible kernelTo decrease thread latency, we chose to make EKA2 multi-threaded,allowing the preemption of low-priority kernel operations by highpriority ones.EKA2 has five threads, and they are:1.

The null thread – idles the CPU, de-fragments RAM. This is alsoknown as the idle thread2. The supervisor thread – cleans up killed threads and processes, provides asynchronous object deletion3. DFC thread 0 – runs DFCs for general device drivers, such as comms,keyboard and digitizer4.

DFC thread 1 – runs the nanokernel’s timer queue5. Timer thread – runs Symbian OS relative and absolute timers(After(), At()).I’ll describe the purpose of these five threads in more detail in Chapter 3,Threads, Processes and Libraries.The multi-threaded nature of the kernel also helped us to achieveanother of our goals – making life easier for device driver writers. Youoften want to port a device driver from another operating system, butthe single-threaded device driver model of EKA1 meant that porting amulti-threaded device driver was not a simple task – you usually had toredesign the driver from scratch.

In EKA2, device drivers can make useof DFC thread 0, or can even create threads of their own if they wish.Device driver designs from other operating systems can be re-used andporting is now much simpler.14INTRODUCING EKA21.3.3.2 NanokernelWe chose to have a separate nanokernel, because it has several advantages:1.Very low and predictable interrupt and thread latencies. This isbecause only the nanokernel disables either interrupts or rescheduling. (There are a handful of exceptions to this, but they are notimportant here.) The vast majority of the Symbian OS kernel, and thememory model, run with both interrupts and preemption enabled.Because the nanokernel provides only a small selection of primitives, it is easy to determine the longest period for which we disableinterrupts or rescheduling2.Simpler and better emulation.

The Symbian OS emulator runningunder Windows has far more code in common with a real device,which means that the emulation is more faithful than that obtainedwith the EKA1 emulator3.Support for single-core phones. The nanokernel allows you to run anRTOS and its GSM signaling stack alongside Symbian OS and its PIMsoftware. For more detail see Section 1.3.2.4.1.3.3.3 ModularityThe increased modularity of the new kernel makes porting the operatingsystem to new ASSPs much easier. A large proportion of the processorspecific code is in the nanokernel, and differences in memory and MMUare confined to the memory model.The memory model makes it easy for you to use the direct memorymodel in the early stages of a port to a new CPU architecture, changingto the moving or multiple models later on when you’ve done moredebugging. It allows you to port the OS in smaller, simpler stages.1.3.3.4 Design limitationsDesigning for real-time performance led to a couple of design limitationson EKA2:1.To ensure deterministic interrupt latencies, we could not allow anunlimited number of interrupt service routines to bind to one interruptsource as was possible in EKA1.

Now only one ISR may bind toan interrupt2.To ensure bounded context switch times, we had to restrict thenumber of chunks in a process to a maximum of 8 – from an unlimited number in EKA1. (A chunk is the Symbian OS object that isfundamental to memory allocation – for more details see Chapter 7,Memory Models.)SYMBIAN OS DESIGN15It’s important to note that not all EKA2 services are bounded in time:for example, the allocation and freeing of memory are potentiallyunbounded. This is discussed in Chapter 17, Real Time.1.3.4 The Symbian OS emulator1.3.4.1 Design decisionsThe emulator has two main uses – developing Symbian OS software anddemonstrating that software.The first of these use cases makes more demands on kernel services, sowe concentrated on it when we drew up our requirements.

At the highestlevel, it gave us just a couple of key requirements for the emulator:1. It needs to support development and debugging using standard toolson the host platform2. It should provide as faithful an emulation as possible of Symbian OSon target hardware.These requirements seem to conflict, because the first requires the use ofentities in the hosted platform (until now, always Windows) that do notexist in the same form in the ‘‘real’’ Symbian OS.