The Design and Implementation of the Anykernel and Rump Kernels

53
while the application logic still remains in the local client. The ability to use multiple
types of clients on a single rump kernel makes it possible to reuse existing tools for
the configuration job and still reap the speed benefit of a local client.
Rump kernels used by remote or microkernel clients always include a local client as
part of the process the rump kernel is hosted in. This local client is responsible for
forwarding incoming requests to the rump kernel, and sending the results back after
the request has been processed.
2.3 Threads and Schedulers
Next, we will discuss the theory and concepts related to processes, threads, CPUs,
scheduling and interrupts in a rump kernel. An example scenario is presented after
the theory in Section 2.3.4. This subject is revisited in Section 3.3 where we discuss
it from a more concrete perspective along with the implementation.
As stated earlier, a rump kernel uses the host’s process, thread and scheduling
facilities. To understand why we still need to discuss this topic, let us first consider
what a thread represents to an operating system. First, a thread represents machine
execution context, such as the program counter, other registers and the virtual
memory address space. We call this machine context the hard context. It determines
how machine instructions will be executed when a thread is running on a CPU and
what their effects will be. The hard context is determined by the platform that
the thread runs on. Second, a thread represents all auxiliary data required by the
operating system. We call this auxiliary data the soft context. It comprises for
example of information determining which process a thread belongs to, and e.g.
therefore what credentials and file descriptors it has. The soft context is determined
by the operating system.