Today (2017 Oct) I realized the origin of the Keykos keeper pattern. When you read a detailed description of a post 1960 CPU you learn about interrupts that switch the CPU from executing one program to some other. These interrupts, along with privileged mode and a few others CPU features turn out to be in support of at least two programs in the machine, one of them, the kernel, fussing over the execution of the other, the client. The kernel is in a position to create all sorts of illusions for the client, such as an illusion of memory far beyond the availability of real memory. The obvious purpose of these entries into privileged mode were immediately provided by operating system kernels. Other uses of these features were not provided and conventional kernels today provide no place to install code to support these new purposes, except, perhaps, in the kernel itself.
What should a kernel do when some user mode program uses a virtual address that is undefined by the current map? The hardware begins to run kernel code while delivering to the kernel the offending virtual address. As hardware manuals describe this feature, they often suggest that the only reasonable response by the kernel is to read a page from the disk, patch the memory map and resume the program. The hardware design is much more powerful than this; the manual underpromises. Perhaps there are several programs sharing a segment RW and these programs are running in different cities. Perhaps the reason for the page fault was that the page in question was at the instant in another city. The response should then be to send a request to that city to fetch that page so that this here program can resume. If the local reference was a write, the request will be for an exclusive copy of the page.
The reader may not think that this is a good plan and indeed it seldom is. Everyone will certainly agree that such logic should not be in the kernel. The point here is that classic kernels do not support this pattern. Some kernels will inform the code that touched the page, but that code may have been designed, written, loaded and launched without this contingency in mind. Further the authority to fetch the page may not properly belong to that code.
This scenario makes more sense if the owner of the segment who set up this peculiar distribution arrangement, provides the code to perform these arcane communication functions. This owner is in a position to create an object that serves as the keeper of the segment. No kernel should include such flakey code.
The Keykos segment keeper pattern assigns a user mode program the responsibility to fix the segment that partially resides in this machine. Programs that deal in primitive data structures to construct a large segment can assign a keeper, which is a cap, to a segment that they construct. Usually they assign a new object that obeys code in the creator. Such code, that is not in the kernel, is in a position to carry out such schemes and not impact other users of the kernel.
Other functions such as ‘copy on write’, pioneered by Unix, can also be removed from the kernel. Keykos has a variety of off-the-shelf segment keepers.
If the program executes a system call for the wrong kernel, because it has been imported, then the Keykos kernel invokes the domain’s domain keeper which can be an object that knows enough about that alien kernel, and is given enough authority, via caps, to satisfy the program so as to continue and serve locally.
If the kernel should get control merely because the program’s macro time slot expired, then that was because someone, a meter keeper, in the CPU time distribution chain said “call me if this here allocation of time is exhausted.”. Thus are macro quantities of CPU time doled out by code outside the kernel.
These are the three sorts of keeper that are defined by Keykos kernel logic. When a keeper gets control it gets an appropriate amount of authority over the domain causing the problem. For instance the meter is unable to trap or interfere with the logic of the domain that blew the time budget. The meter keeper can merely delay it. The segment keeper cannot peer into the registers of the running domain. It gets enough authority to fix the segment. The domain keeper can read and even write the registers of the faulted domain.
The keeper pattern needs to be extended to some objects outside the kernel, like the space bank.