Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 4
Текст из файла (страница 4)
And late on the Friday afternoon,the null thread finally printed out its debug message – EKA1 was born.But EKA1 was not destined to be the end of the story. The Symbian OSsystem for supporting event-driven programming was efficient overall,but provided no real-time guarantees. The kernel itself was designedwith robustness – key for PDAs that hold a user’s personal data – as theprimary goal. As Symbian OS began to address the processing needsof mobile phones, it became apparent that an OS that could providereal-time guarantees was really needed.There were other influences on EKA2 too.
The experience gainedfrom real hardware porting in the context of EKA1 was beginning todemonstrate that EKA1’s module boundaries were not always drawn in theright place to make porting easy. Some ports, which should have requiredonly a driver change, in practice required the kernel to be re-built.So a new kernel architecture was conceived and, to distinguish itfrom the original 32-bit EPOC kernel, it was named EKA2 (EPOC KernelArchitecture 2), with the term EKA1 being invented for the original.BASIC OS CONCEPTS3EKA2 was conceived in 1998 and, little by little, brought from drawingboard to market.
By 2003, Symbian’s lead licensees and semiconductorpartners were committed to adopting EKA2 for future products.This book was written to provide a detailed exposition on the newreal-time kernel, providing the reader with the insights of the softwareengineers who designed and wrote it.This chapter is designed as the foundations for that book and shouldgive you a good understanding of the overall architecture of the newreal-time kernel, and of the reasoning behind our design choices.
I willalso say a little about the design of the emulator, and then return to thissubject in more detail a couple of times later in the book.1.2 Basic OS conceptsI’d like to start with a basic definition of an operating system (OS):The operating system is the fundamental software that controls theoverall operation of the computer it runs on. It is responsible for the management of hardware – controlling and integrating the various hardwarecomponents in the system.
The OS is also responsible for the management of software – for example, the loading of applications such as emailclients and spreadsheets.The operating system is usually the first software that is loaded into acomputer’s memory when that computer boots. The OS then continuesthe start-up process by loading device drivers and applications. These,along with all the other software on the computer, depend on theoperating system to provide them with services such as disk access,memory management, task scheduling, and interfacing with the user.Symbian OS has a design that is more modular than many other operating systems. So, for example, disk services are in the main performedby the file server, and screen and user input services by the windowserver.
However, there is one element that you can think of as the heartof the operating system – the element that is responsible for memorymanagement, task management and task scheduling. That element is ofcourse the kernel, EKA2.There are many different flavors of operating system in the world, solet’s apply some adjectives to Symbian OS, and EKA2 in particular:Symbian OS and EKA2 are modular. As I’ve already said, operating system functionality is provided in separate building blocks, not one monolithic unit. Furthermore, EKA2 is modular too, as you can see in Figure 1.1.EKA2 is single user. There is no concept of multiple logins to aSymbian OS smartphone, unlike Windows, Mac OS X, UNIX or traditionalmainframe operating systems.EKA2 is multi-tasking. It switches CPU time between multiple threads,giving the user of the mobile phone the impression that multiple applications are running at the same time.4INTRODUCING EKA2EWSRVEFILE(window server)(file server)ESTARTEUSERHAL(user library)privilege userboundary kernelDEVICEDRIVEREKERN(kernel)memorymodelnanokernelEXTENSIONLDDPlatformIndepentLayerPDDPlatformSpecificLayerASSPRTOSPERSONALITYLAYER(EXTENSION)variantphysical softwareboundary hardwareMMUCPUPeripheralsPic& timerBSPboundaryFigure 1.1 Symbian OS overviewEKA2 is a preemptively multi-tasking OS.
EKA2 does not rely onone thread to relinquish CPU time to another, but reschedules threadsperforce, from a timer tick.EKA2 is a priority-based multi-tasking OS with priority inheritance.EKA2 allocates CPU time based on a thread’s priority and minimizes thedelays to a high-priority thread when a low-priority thread holds a mutexit needs.EKA2 is real-time. Its services are (mostly) bounded, that is it completesthem in a known amount of time.EKA2 can be a ROM-based OS.EKA2 is suitable for open but resource-constrained environments. Wedesigned it for mobile phones, and so it needs less of key resources suchas memory, power and hard disk than open desktop operating systemssuch as Windows or Linux.1.3 Symbian OS design1.3.1Design goalsWhen creating EKA2 we set ourselves a number of design constraints. Westarted by deciding what we didn’t want to lose from EKA1.
This meantthat we wanted to ensure that the new kernel was still:1.In the embedded OS tradition2.Suitable for resource-constrained environmentsSYMBIAN OS DESIGN53. Modular: consisting of microkernel and user-side servers4. Portable to a range of evolving chipsets5.
Robust against badly written user code6. Of high integrity, ensuring the safety of user data.Then we decided on our new goals. The key goal was that the newkernel would be real-time and have enhanced overall performance. Wedecided that we would meet this if we could run a GSM protocolstack on our new operating system.
A side benefit, and a worthy one,would be the ability to better support high-bandwidth activities such ascomms and multimedia. This goal broke down into several sub-goals andrequirements:1. Latency ≤ 1 ms from interrupt to user thread2. Latency ≤ 500 µs from interrupt to kernel thread3. Fast mutex operations4.
OS calls to be of determined length where possible5. OS calls to be preemptible6. Priority-order waiting on semaphores and mutexes7. Timers with a finer resolution.Then we considered how else we could improve the operating system,and we came up with the following list:1. Ease porting – although EKA1 had been designed to be portable, wecould go much further to make life easier for those porting the OS tonew hardware2. Be robust against malicious (rather than merely badly written) usercode3. Enable single-core solutions, in which embedded and user-applicationcode run on the same processor core4.
Provide a better emulator for code development and debugging, thatemulator being a closer match to real hardware5. Simplify life for device driver writers.And as we considered these design goals, we were aware that therewas one over-riding constraint on our design. That constraint was tobe backwards source compatibility with the EKA1’s EUSER class library.6INTRODUCING EKA2EUSER is the interface to the kernel for all Symbian OS applications, andthere are a lot of them out there!1.3.2 Symbian OS kernel architectureWith those design goals in mind, we designed an operating system whosearchitecture, at the highest level, looked like that in Figure 1.1. You cansee the major building blocks of the kernel.
I’ve also included two otherkey system components that are usually considered to be part of theoperating system, and that I will cover in this book: the file server and thewindow server. I’ll cover each of these building blocks and give you anidea of its basic functionality.1.3.2.1 NanokernelThe main function of the nanokernel is to provide simple, supervisor-modethreads, along with their scheduling and synchronization operations. Wenamed the nanokernel as we did because the services it provides areeven more primitive than those provided by most embedded real-timeoperating systems (RTOSes).
However, we have carefully chosen thoseservices to be sufficient to support a GSM signaling stack.The nanokernel is the initial handler for all interrupts. It then passesthe majority of them to the variant layer for dispatch. It also providessimple timing functions, such as the nanokernel timer (NTimer) API,which gives a callback after a specified number of ticks, and the sleep API(NKern::Sleep), which makes the current thread wait for a specifiednumber of ticks.The simple synchronization objects I mentioned earlier are the nanokernel mutex (NFastMutex) and the nanokernel semaphore (NFastSemaphore). Both of these forbid more than one thread from waitingon them.Finally, the nanokernel provides deferred function calls (DFCs) and theoddly named immediate deferred function calls (IDFCs). If you want tofind out more about these, then please turn to Chapter 6, Interrupts andExceptions.An important difference in EKA2 from EKA1 that should be noted isthat neither the nanokernel nor the Symbian OS kernel link to the userlibrary, EUSER.
Instead, the nanokernel uses its own library of utilityfunctions, and makes these available to the rest of the kernel, and devicedrivers too.Another key difference from EKA1, somewhat related to the one Ihave just discussed, is that EKA2 does not support a kernel-side leavingmechanism. This means that errors are reported by returning an errorcode – or panicking the thread.The majority of the time, the nanokernel is preemptible. Usually itruns unlocked and with interrupts enabled, but we do have to preventSYMBIAN OS DESIGN7other threads from running in a few sections of code, such as thread statechanges and access to the ready list.
We designed these critical sectionsto be as short as possible and to have bounded execution times, thegoal being to maintain deterministic real-time performance. We protectthe critical sections in the nanokernel by disabling preemption – this ispossible because these sections are very short. In general, we use a mutexknown as the system lock to protect critical code in the Symbian OSkernel and memory model, but the only place where the nanokernel usesthis lock is to protect the scheduler’s address space switch hook on themoving memory model.What are the limitations on the nanokernel? The main one to noteis that it does not do any dynamic memory allocation; that is, it can’tallocate or free memory.
In all of the nanokernel’s operations, it assumesthat memory has been preallocated by other parts of the operating system.1.3.2.2 Symbian OS kernelThe Symbian OS kernel provides the kernel functionality needed bySymbian OS, building on the simple threads and services provided by thenanokernel to provide more complex objects, such as user-mode threads,processes, reference-counted objects and handles, dynamically loadedlibraries, inter-thread communication and more.These objects also include a range of more sophisticated synchronization objects: Symbian OS semaphores and mutexes. Symbian OSsemaphores are standard counting semaphores which support multiplewaiting threads and which release waiting threads in priority order. Symbian OS mutexes are fully nestable (a thread can hold several mutexes atonce, and can hold the same mutex multiple times).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
