Don’t Monopolize Hardware Features

Modern hardware provides a few nice extensions over earlier computing schemes. In particular consider that it is possible to install code X in a machine to react to another program Y attempting to access certain addresses. X gets control so as to be able to provide an environment for Y functionally equivalent to one where the data at those addresses was already there.

Almost all operating systems have monopolized this functionality, saying, it would seem, that only the OS was smart enough to use such a feature. Features such as copy-on-write became available only when some kernel programmer got around to installing such function in the kernel. Other features such as compute-the-data-when-it-is-needed, remain unavailable to the application builder. Normal computer science practice is to export functionality thru perhaps an API so that user programmers can harness it.

It is true that some Unix systems allow the program to divert access faults to code in the same address space as the program suffering the fault. This is very inconvenient as it requires that the program providing the illusion share the address space of the program which is to benefit from the illusion. It is often the case that the illusion provider does not have access to forms of the code that is necessary for this approach.

It was, I think, the great achievement of Unix to make the shell an unprivileged user program. Such function in previous systems had been highly privileged or even integrated with the kernel. More such function needs to be removed as a monopoly of the privileged code.

The Unix proc facility gives a program somewhat general access to the state of another process. Many CPU scheduling schemes are available to the kernel while only crude time allocation policies may be built outside the kernel.

The general keeper pattern of Keykos mechanism attempts to export all of these goodies, safely, to the application programmer.