The Keykos kernel is a body of code that defines and imposes capability discipline and also hosts several types of object (kernel objects) that for various reasons (including performance) need the excessive authority of privileged mode. Kernel objects conform voluntarily to capability discipline.
This is a collection of notes on the implementation of the Keykos kernel.
The kernel logic manual was the design document for the 370 kernel. When a discrepancy between the manual and the kernel code was found, the code was deemed to be wrong!
First there are a few historical and philosophical notes about patterns found in the kernel and antecedents to these patterns. See adapted data for notes on streamlining node state for accelerating kernel transactions, and adaptive formats for precursors. Next some platitudes on why the kernel is fast, large, and yet trustworthy:
The kernel is bigger than its semantics would suggest in part for reasons of efficiency. Considerable additional code is devoted to guarding against bugs in this extra code, and incidentally transient hardware errors.Here are some notes on kernel integrity and on why the kernel does not run out of RAM, How the kernel exploits its privileges and projects to decrease kernel bugs.
EROS hackers will find little new so far. This terminology map between Keykos and EROS may help in the following. Next there is some meat where Keykos differs from EROS: Prepared keys allow for quicker access to the object designated by a key. Prepared keys are also quickly found starting from the thing they designate. The kernel queue structure exploits this. You might start exploring at the core table. Item Space is strategic in all of this.
Nodes may also be prepared and this leads to involved keys.
Here are the particular ways that nodes may be prepared:
Meters are much more efficient than their external specs suggest.
Domains are adapted for quick starts and stops.
The prepared segment is the most complex of the data adaptations.
Then there is the broader set of lazy strategies.
Revoking access to memory,
Kernel Disk Logic
We describe and motivate the depend relation by expounding a bug therein, and its fix.
The kernel deals with locks in a unified fashion and observes a ‘dry run’ discipline.
Some notes on the 370 kernel and general multiplexing strategies.
Here are some notes that I made as we adapted the C code to the SPARC architecture.
Here is a note about requiring kernel additions to be unnecessary.
A note about caches for kernel structures
The simplest message from one domain to another took about 100 kernel instructions. Of course some of these instructions would wipe out the Hardware’s cache of address maps (TLB) on some models but not others. In wiped, it was necessary to count the cost of reloading that cache. On the 370 the kernel did not burden the TLB.