Prior to kernel design is the very concept that keys (capabilities) designate things and convey authority over those things. Somewhat novel to Keykos was the plan to deliver small identifiable units of hardware function via keys. Thus the page became an object whose use and protection were via keys. The other principles might be claimed by any kernel design.
  1. Deliver hardware function as best you can without attenuating it. Minimize the opportunity of the applications programmer to say “I could do it better on the raw hardware.”. “Faster?” perhaps — “better?” No.
  2. Make the hardware safe for sharing. This comes under the term “multiplexing”. This includes protecting one program from another.
  3. Allow whatever communications are mutually desired. That is not contrary to confinement—we will weasel around later.
  4. Provide whatever bottoming out services are required logically or for performance reasons.
Independently we decided to provide persistence because we wanted the arrangements manifest by the distribution of keys to be uniform across time scales rather than to provide hooks to reinstate these arrangements from “stable storage”. Systems that take this conventional approach require that application and system code take steps to “stabilize” state here and there. It is often difficult for the code to gain the perspective necessary to decide when to do this. Many of the designs of code outside the kernel work on time scales from milliseconds to years. A uniform stabilization policy would make them unusable on the millisecond scale and the opposite decision makes them unusable on the time scale. Checkpoint and restart was non-trivial to do but it was trivial to specify! It simplified so much code outside the kernel.

Checkpoint logic and the decision to rely on it, dictated very reliable storage. Thus mirroring (RAID) in the kernel.

Kernel Strategies

There is just one explicit kernel invocation: to invoke a key. On specific machines there were a few other special cases such as:
Priv Op Emulation on 370
We wanted to run IBM’s CMS system, in an interactive development environment. CMS uses a few privileged instructions frequently which the kernel emulated, if options were selected via the domain key. This was purely for performance. The domain keeper could do this but more slowly.
Compare and Swap on the 88K
The 370 had taught us that the compare and swap instruction was very useful. The 88K lacked such an instruction and so we allocated an invalid 88K opcode for that function which we provided in the kernel. This was more for convenience than performance.
Other events that cause the kernel to start running are: Each of these events might influence which domain would next run when the event had been dealt with.