Here is a note on the original keepers for Keykos kernel objects.
The sections below, separated by rules, represent successive attempts to capture the essence of keepers.
Evidently it is elusive.
Alas this note is deeply wedded to the call stack view of computing.
The keeper pattern is parasitic on the service key pattern.
Extending the analogy used to describe service keys, the keeper is the person in the office who you call when the service key must be used to proceed with normal usage of the copier.
In the capability keeper pattern the kept object retains a key (capability) to the keeper and the general user is not involved in invoking the keeper.
When the keeper is called a service key is included in the message to the keeper.
Some useful object type has been defined.
It has some simple property that is desirable and easy to understand, and there is base code that is widely believed to provide objects with that property.
There is an additional property typically needed for some instances of this type.
This additional property may be desired by others.
The new property could be added to the base code but:
- Not all instances of the type need the additional property.
- Different instances may need different additional properties.
These are roughly the circumstances where OO inheritance is usually recommended.
With either inheritance or keepers new code provides the new property.
There is a fundamental advantage of the keeper style of sub-type:
The code for the base object can ensure that simple properties are maintained.
I don't know whether "final" attributes in Java can maintain properties for subtypes.
Why are we interested in object properties that are desired by someone other than the wielder of the object?
- I may give you a read facet to my file with which you can read but not change my file, even if you desire to.
- I may have an object U that reveals the current weather in any US city.
I may want to give you an object B that only reveals the current weather in Boston.
The easiest way for me to build B is to build a new object that wields U but refuses to ask U about any city but Boston.
The property that you desire is that it is accurate about Boston.
I desire the property that B conceals the other information that U reveals.
Here is an older description which may be melded into this.
Consider a class C of objects where creation of an object of that class takes an argument P which is a procedure.
C objects have property c in common.
The procedure that a particular object of class C is created with gives it further properties that are not shared with other objects of class C.
Programs using an object of class C may rely on c without relying on the particular additional properties stemming from its particular argument.
Suppose object B holds an object of class C internally as an element.
Some properties of B will depending on the code that implements B, stem from the fact
Some programs can rely on an object of class C because of property c.
Some refined facility is required.
The crude capabilities are too powerful to be held by one program.
Not quite!
I abstract here from the Keykos segment keeper design.
There are two programs involved in presenting the illusion of a kept segment: the kernel and the keeper.
The kernel alone is trusted to manipulate the real mapping tables consulted by the real hardware map.
One of several keepers is involved in the higher level issues of allocating pages and build a multilevel tree to link the pages together.
There are just a few common segment keepers but a variety of keepers that specialize in the needs of some particular task.
Putting each of these in the kernel is not compatible with a stable kernel.
The two components of the solution are:
- the kernel
- with its simplicity mandate, and
- the keeper
- with its specialized knowledge and strategy for delivering some particular sort of segment behavior.
The meter keeper has a different rationalization.
The job is again split in two:
- The kernel
- which has direct privileged access to the hardware timing facilities.
It provides the illusion that counters in the meters superior to a running domain always run, which is simpler than it sounds.
It detects exhaustion of a counter in a meter and invokes the meter’s keeper.
- The keeper
- which performs some scheduling policy which may be chosen by the system or by the application.
There are many possible policies including schemes to limit covert channels.
In this case the keeper plays a police function as well as a diversity role.