Styles of Kernel

We introduce some nearly conventional terminology here with which to contrast three styles of kernel architecture:

conventional, such as Unix,
virtual machines
capability, such as Keykos

Any of these kernels:

runs on bare hardware,
provides multiple concurrent environments for apps (applications),
provides some degree of privacy to those apps,
provides permanent data objects, such as files,
provides some means for programs in an environment to act (peform actions) in order to sense and modify files,
multiplex the physical machine resources between the environments.

Our term file here is inappropriate for any of these categories but we need such a term: I need to say here which things from each style constitute a “file” in this model!

The Unix file directory holds many things besides files,
A virtual machine kernel is unlikely to provide anything so luxurious as a file, but it may provide raw disk space,
A capability kernel provides primitives by which file like objects are easily constructed.

These environments generally include an address space separate from the other environments. Un vetted code is allowed to run in these address spaces so that code in one environment is not at risk from memory accesses by code in another. The allowed actions are generally controlled in a way depending on the kernel style. This privacy is somewhat analogous to what people want and is instrumental in providing privacy for people. Each of these kernels multiplex the physical machine resources so that the apps need not be excessively concerned with this.

The last few decades have seen a substantial body of software function, such as data base software, that is outside the kernel but also outside the application. We refer to that as middleware here. Middleware runs in its own environment and too often these environments require universal authority to do their job.

Conventional Kernels

Conventional kernels have a built in notion of user with which environments and files are associated. An action by a program in an environment on a file is generally allowed when the environment and file are associated with the same user. Access lists attached to a file may allow additional access by environments of other users.

The most familiar programming context is provided by standard libraries that run in the address space of the environment. These libraries run with the environment’s authority and invoke the conventional kernel to perform the actions on files.

Virtual Machine Kernels

The environment provided by a virtual machine kernel is called a virtual machine, naturally. The virtual machine is functionally equivalent to a real machine and programs that finds a real machine suitable will run in a virtual machine. Today this usually means that some conventional OS runs on a virtual machine in order to support “useful” programs.

Just as real machines communicate by features such as Ethernet or shared disks, so may virtual machines. Virtual machine kernels often allow some special virtual machine to control what other connections are permitted between the other virtual machines. Software in the special machine can thus institute security policies.

Virtual machine systems, by them selves, do not provide a “civilized” programming environment. On the other hand they allow any other sort of environment to be used.

Capability Kernels

The capability style kernel provides environments which are able to efficiently invoke programs in other environments by sending messages. Many of the functions of a Unix style kernel are thus provided by programs that run in these environments and the capability kernel is thus much smaller than a Unix style kernel.

An environment in a capability system has a list of capabilities that the program therein can use as it pleases. These capabilities are used primarily as addresses for these messages. Some capabilities locate other environments and a message addressed by such a capability is delivered to the program in that environment. Messages to other capabilities are interpreted by kernel code. To send a message to a capability is to invoke that capability. Such a message can include other capabilities from the sender’s list, whereupon the message recipient receives that capability into its own capability list. Capabilities can be thought of as references to objects.

There are capabilities to produce new environments and introduce code to be executed therein. To invoke a capability is the sole means of acting.

Collections of environments without capabilities between them remain isolated from each other for no messages can flow between them. This is a trivial way to provide the isolation that is so natural to the virtual machine system.

The programming context in a capability system depends on the available objects. Middleware lives in its own environments just as do the apps and most OS functions found in conventional kernels.

Keykos, in contrast to Mach, emphasizes multiply instantiated objects. In Keykos the sorted list function will be provided as one object per list, in its own environment. In Mach the pattern is to put all sorted lists in one environment.