- From Another EPOC
- A Tiny Kernel
- Building a Real OS
- Symbian Security
- Power to the People
- Drivers
- A Modern System
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building a Real OS
The nanokernel fills a role similar to that of the Hardware Abstraction Layer (HAL) in Windows NT or Mach in OS X. It provides an absolute minimum set of core functionality required to implement the rest of the OS. A lot of code in the nanokernel is platform-specific, but very little outside the nanokernel is so specific.
An operating system has two responsibilities:
- Isolating running applications from each other
- Isolating running applications from the hardware
These responsibilities are partly about security and partly about reliability. One program attempting to tamper with another may be doing so maliciously, or it may simply be poorly written. Classic Mac OS, for example, was notoriously unstable because it didn't isolate processes from each other. A bug in one program could overwrite another program's memory, causing it to access a third program's memory, and so on until the whole system was broken.
The second role is partly about security—because applications that can access the hardware directly can do anything—but mainly about convenience. If I'm writing a 3D application, I don't want a different code path for every possible GPU. If I'm playing sound, I don't want different code for every possible sound device. The operating system's job is to provide higher-level abstractions that I can use instead.
The Symbian operating system is a multi-server microkernel. Outside of the nanokernel is a microkernel, which provides the core functionality for an operating system on top of nanokernel primitives. This includes a memory model object, encapsulating the behavior of the MMU (or absence of MMU). With the memory model loaded, the microkernel can allocate memory dynamically and set up process boundaries. It also provides a rich set of interprocess communication (IPC) primitives, including things like message queues and semaphores.
Because it was created for mobile devices, the Symbian process model is designed around reducing RAM usage. Like most modern operating systems, it aggressively tries to share memory where possible. If you load the same program or library twice, you'll get at most one copy of the program code in memory. If the program is stored on something like on-chip flash, it might be used in-place. "Execute in place" requires the executable to have been specially built not to require any relocation information, for example, and it must be stored on a device that the CPU can access as if it were RAM.
If you write POSIX code on Symbian, you'll notice that it has no equivalent of fork(). This call on UNIX systems is a holdover from very old minicomputer architectures that didn't have protected memory. On a context switch, they would write the current process out and load another one in. When you created a new process, you got a copy of the old one for free. On modern UNIX systems, a huge amount of effort is made with copy-on-write hacks, to pretend that this is still the case. This history doesn't exist with Symbian, so it has no fork() analog. To create a new process, you specify a program binary and get a completely new process, not a copy of the old one.