When a user mode program traps there is some domain D, that is obeying that program. If the trap is caused by an address that the hardware memory map does not define the kernel first tries to extend the map to include that address. This may require disk I/O whereupon the CPU may switch to other domains while the I/O finishes. Perhaps instead the D’s address segment fails to define this address. Sometimes then a segment keeper is invoked to extend the definition of some segment which contributes to D’s address segment. Failing a suitable segment keeper D’s domain keeper is invoked buy the kernel.

The domain keeper is a program that is invoked when a domain program suffers other faults as it runs in user mode; the kernel begins to obey the domain keeper upon traps defined by the hardware. The domain keeper is within the design pattern of keepers. The one trap that does not invoke the keeper is that trap defined to invoke a key held by the domain. Here is the most detailed definition.

The keeper slot of a domain holds keeper key which nominates the keeper for the domain. As a domain obeys code which results in a trap, that domain’s keeper is invoked by the kernel. The keeper key is almost always a start key to a different domain which might share its address space with the trapped domain. When the domain keeper is invoked the message includes the domain key and the restart key to the trapped domain. Coded information detailing the hardware’s view of the trap is also included. The keeper is thus in a position to respond to the trap much as a classical operating system would by wielding the domain key, but as confined by capability discipline.

The domain key permits intervention in the logic of the program obeyed by the domain, whether or not the domain is trapped. The abstraction level is that of the application architecture of the hardware but including the capabilities held by the domain.