Symbian OS kernel architecture
With those design goals in mind, we designed an operating system whose architecture, at the highest level, looked like that in Figure 1.1. You can see the major building blocks of the kernel. I've also included two other key system components that are usually considered to be part of the operating system, and that I will cover in this book: the file server and the window server. I'll cover each of these building blocks and give you an idea of its basic functionality.
1.3.2.1 Symbian OS Kernel" href="/kernel/nanokernel-timers.html">Nanokernel
The main function ofthe nanokernel isto provide simple, supervisor-mode threads, along with their scheduling and synchronization operations. We named the nanokernel as we did because the services it provides are even more primitive than those provided by most embedded real-time operating systems (RTOSes). However, we have carefully chosen those services to be sufficient to support a GSM signaling stack.
The nanokernel is the initial handler for all interrupts. It then passes the majority of them to the variant layer for dispatch. It also provides simple 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 specified number of ticks.
The simple synchronization objects I mentioned earlier are the nanokernel mutex (NFastMutex) and the nanokernel semaphore (NFast-Semaphore). Both of these forbid more than one thread from waiting on them.
Finally, the nanokernel provides deferred function calls (DFCs) and the oddly named immediate deferred function calls (IDFCs). If you want to find out more about these, then please turn to Chapter 6, Interrupts and Exceptions.
An important difference in EKA2 from EKA1 that should be noted is that neither the nanokernel nor the Symbian OS kernel link to the user library, EUSER. Instead, the nanokernel uses its own library of utility functions, and makes these available to the rest ofthe kernel, and device drivers too.
Another key difference from EKA1, somewhat related to the one I have just discussed, is that EKA2 does not support a kernel-side leaving mechanism. This means that errors are reported by returning an error code - or panicking the thread.
The majority of the time, the nanokernel is preemptible. Usually it runs unlocked and with interrupts enabled, but we do have to prevent other threads from running in a few sections of code, such as thread state changes and access to the ready list. We designed these critical sections to be as short as possible and to have bounded execution times, the goal being to maintain deterministic real-time performance. We protect the critical sections in the nanokernel by disabling preemption - this is possible because these sections are very short. In general, we use a mutex known as the system lock to protect critical code in the Symbian OS kernel and memory model, but the only place where the nanokernel uses this lock is to protect the scheduler's address space switch hook on the moving memory model.
What are the limitations on the nanokernel? The main one to note is that it does not do any dynamic memory allocation; that is, it can't allocate or free memory. In all of the nanokernel's operations, it assumes that memory has been preallocated by other parts of the operating system.
Post a comment