Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 5
Текст из файла (страница 5)
They also supportpriority inheritance: the holding thread inherits the priority of the highestpriority waiting thread, if that is higher than its usual priority.In contrast to the nanokernel, the Symbian OS kernel does allowdynamic memory allocation. It provides a kernel memory allocator – thekernel heap, which uses low-level memory services provided by an entityknown as the memory model. The Symbian OS is completely MMUagnostic – we isolate all assumptions about memory to the memorymodel, which I describe in more detail in the next section.The Symbian OS kernel is fully preemptible: an interrupt can causeit to reschedule at any point in its execution, even in the middle of acontext switch.
This means that the Symbian OS kernel can have no effectwhatsoever on thread latency.We use system lock mutex, provided by the nanokernel, to protect themost fundamental parts of the Symbian OS kernel, such as:(i)The state of DThread objects. When Symbian OS threads interactwith semaphores and mutexes, they undergo state transitions thatare protected by the system lock8INTRODUCING EKA2(ii)The state of most Symbian OS synchronization objects: IPC (serversand sessions), semaphores, mutexes, message queues, publish andsubscribe properties(iii)Handle arrays are valid for reading (but not writing) when the systemlock is held.
All the executive functions that take a handle hold thesystem lock while translating it – see Chapter 5, Kernel Services, formore on this subject.1.3.2.3 Memory modelIn EKA2, we confine our assumptions about the memory architecture ofthe ASIC to one module, the memory model. Thus the memory modelencapsulates significant MMU differences, such as whether a cache isvirtually tagged or physically tagged, and indeed, whether there is anMMU at all. In EKA1, assumptions about memory and the MMU werespread throughout the operating system, making it difficult to producea mobile phone based on an ASIC without an MMU, for example.
Thishas become much easier with the advent of EKA2, since the memorymodel allows you to model memory in different ways, and to change thatdecision relatively easily.Symbian currently provides four different memory models:1.Direct (no MMU)2.Moving (similar to EKA1)3.Multiple (used for ASICs with physically tagged caches such as IntelX86 and later ARM cores)4.Emulator (used by the Symbian OS emulator that runs on Windows).The memory model provides low-level memory management services,such as a per-process address space and memory mapping. It performsthe context switch when asked to do so by the scheduler and is involvedin inter-process data transfer.The memory model also helps in the creation of processes as aninstantiation of an executable image loaded by the file server, and takespart in making inter-process data transfers.If you are interested in finding out more about the memory model, turnto Chapter 7, Memory Models.1.3.2.4 Personality layerWe designed the nanokernel to provide just enough functionality torun a GSM signaling stack.
The idea behind this was to allow mobilephone manufacturers to run both their signaling stacks and their personalinformation management (PIM) software on a single processor, providingconsiderable cost savings over the usual two-processor solution.SYMBIAN OS DESIGN9Most mobile phone manufacturers have written their signaling stacksfor existing RTOSes such as Nucleus or µITRON. These signaling stacksrepresent a considerable investment in time and money, and it would bevery time-consuming for the mobile phone manufacturers to port themto the nanokernel – not to mention the increase in defects that wouldprobably ensue from such an exercise.Because of this, we designed the nanokernel to allow third partiesto write personality layers.
A personality layer is an emulation layerover the nanokernel that provides the RTOS API to client software. Thepersonality layer would translate an RTOS call into a call (or calls) tothe nanokernel to achieve the same ends. In this way, we allow sourcecode written for that RTOS to run under Symbian OS with little or nomodification.For a more detailed description of personality layers, and the nanokernel design decisions that support them, turn to Chapter 17, Real Time.1.3.2.5 ASSP/variant extensionTypically, the CPU and the majority of hardware peripherals on mobiledevices are implemented on a semiconductor device integrated circuitcommonly referred to as an ASSP (Application-Specific Standard Product).To reduce both the bill of materials and the size of a phone, it is becoming common to add an increasing number of components to the ASSP.This might include stacking RAM and flash components on the samesilicon package, or incorporating components into the silicon layout; forexample, a DSP (digital signal processor) for audio/video processing, dedicated graphics processors and telephony baseband processors runningGSM or CDMA communication stacks.We refer to any hardware components outside the ASSP as variantspecific components.
These typically include components such as flashand RAM storage technology, display devices, baseband and Bluetoothunits. They are typically interfaced to the processor over semiconductorvendor-specific buses and interconnect, or more standard communications lines such as USB and serial UARTs. ASSPs also tend to provideconfigurable GPIO (general purpose I/O) lines for custom functions suchas MMC card detect and touch-screen pen down interrupt lines.So, in Symbian OS, the ASSP/variant extension provides the hardwaredependent services required by the kernel – for example, timer tickinterrupts and real-time clock access. In the days of EKA1, we builtthe ASSP into the kernel, and the separate variant layer described in thenext section was mandatory. This made for unnecessary re-compilation ofthe kernel when porting to a new ASSP, so in EKA2 we have completelyseparated the ASSP from the kernel.
Of course, this means that if you areporting EKA2, you no longer need to recompile the kernel every time youtweak your hardware.10INTRODUCING EKA21.3.2.6 VariantIn EKA2, we don’t insist that you make a division between the ASSP andthe variant, as we do in EKA1. You may provide one single variant DLL ifyou wish. Nevertheless, if you were porting the OS to a family of similarASICs, you would probably choose to split it, putting the generic code forthe family of ASICs in the ASSP extension, and the code for a particularASIC in the variant DLL.
For example, within Symbian, the Intel SA1100ASSP has two variants, Brutus and Assabet.1.3.2.7 Device driversOn Symbian OS, you use device drivers to control peripherals: driversprovide the interface between those peripherals and the rest of Symbian OS. If you want, you may split your device driver in a similarway to the ASSP and variant, providing a hardware-independent logicaldevice driver, or LDD, and a hardware-dependent physical device driver,or PDD.Device drivers may run in the client thread or in a kernel thread:our new multi-threaded kernel design makes porting device drivers toSymbian OS from other operating systems much easier.Symbian provides standard LDDs for a wide range of peripheral types(such as media devices, the USB controller and serial communicationsdevices) – nevertheless, phone manufacturers will often develop theirown interfaces for custom hardware.Device drivers have changed considerably from EKA1 to EKA2. SeeChapter 12, Drivers and Extensions, for more details.1.3.2.8 ExtensionsExtensions are merely device drivers that the kernel automatically startsat boot-time, so you can think of them as a way to extend the kernel’sfunctionality.
For example, the crash debugger is a kernel extension,allowing you to include it or exclude it from a ROM as you wish, withouthaving to recompile the kernel.The variant and the ASSP that I discussed earlier are important extensions that the kernel loads quite early in the boot process. After this, thekernel continues to boot until it finally starts the scheduler and entersthe supervisor thread, which initializes all remaining kernel extensions.Extensions loaded at this late stage are not critical to the operation ofthe kernel itself, but are typically used to perform early initialization ofhardware components and to provide permanently available services fordevices such as the LCD, DMA, I2C and peripheral bus controllers.The final kernel extension to be initialized is the EXSTART extension,which is responsible for loading the file server. I discuss system boot inmore detail in Chapter 16, Boot Processes.SYMBIAN OS DESIGN111.3.2.9 EUSERThe user library, EUSER, provides three main types of function to itsclients:1.