Chapter 1

The kernel itself has two major components:
� The kernel executive runs privileged code on behalf of a user thread, and runs in the
context of that user thread.
� The kernel server is the main thread of its own process and always runs privileged.
The kernel server is the highest-priority thread in the system. It allocates and
deallocates kernel-side resources needed by the system and by user programs. It also
performs functions on behalf of user-mode programs. The kernel server is a single
thread: it handles user requests in sequence, non-preemptively.
Figure 2.5
We'll be describing euser.dll's most important facilities in detail over the next few
chapters. For now, let's note that it offers three types of functions:
� Functions that execute entirely user-side, such as most functions in the array and
descriptor classes (descriptors are the Symbian OS version of strings).
� Functions that require privilege, and so cross into the executive, such as checking the
time or locale settings.
� Functions that require the services of the kernel server: these go through the user
library, via the executive, to the server.
The functions that operate entirely on the user-side can also be used safely by any kernelside
code. Kernel-side code that needs access to kernel facilities can (and must) use these
facilities directly rather than through the user library interface.
In this book, we'll be writing user-side code exclusively. So, although the distinction between
the types of function in the user library helps you to understand the system design, it's not
essential for you to know all the possible circumstances in which kernel-side code might be
called.
2.7 Device Drivers
System devices such as screen, keyboard, digitizer (for the pen), sound codec, status LEDs,
power sensors, serial port, CF-card, and so on are all driven by low-level device drivers. It's
possible to add devices and write drivers for them. Symbian OS OEMs usually do this:
Symbian OS phones are not typically user-expandable in the same way that PCs are.
A device driver is implemented in several parts as shown in Figure 2.6: