UP
Phenomena can be described at different levels of abstraction.
For example, the “IBM System/370 Principles of Operation”
{order number GA22-7000} describes certain computers from
a level of abstraction appropriate for some programmers,
but omits details of the implementation which might interest
a field service engineer. Information for a field service
engineer would omit detail that might interest a physicist.
While descriptions at one level of abstraction suppress
detail, they need not be imprecise. The “S/370 Principles
of Operation” includes all of the information needed to
explain a certain and important class of programs.
This document is intended to be useful at many levels
of abstraction. We omit all detail inside the kernel, that
is, everything that happens in supervisor state. For those
details, see (kernel-logic,).
What remains is called the kernel level of description.
A level of description can be characterized by defining a
set of keys that are to be considered irrelevant detail.
A description at such a level would omit detail in any domain
that has access to any key in the set, and treat the domain
as a black box. The term “level” is not entirely appropriate
because such sets of keys are not simply ordered in Gnosis.
{kernel}Some levels of description commonly used in this
manual are defined here. Sometimes it is clear from context
what level of description is being used. {Unfortunately,
not always.}
The term “extended kernel” has been used to mean levels
of description which exclude detail involving some of the
following keys that provide services to the kernel: the
migrate key, the external returner, the decongester tool,
the error key, the peek key.
{arcane}LOOSE END: this should be made more precise.
Some parts of the kernel algorithm involve code and
data that can be conveniently run in user mode. These routines
can be thought of as subroutines of the kernel; but there
is a delicate recursion that limits programming techniques
that may be used in these external kernel parts. The fact
that the kernel chooses to run these routines in user mode
is of consequence only to those who are concerned with the
implementation of the kernel. This strategy involves esoteric
keys which are in some sense of no business to those outside
the kernel.
An interesting example is the external migrator. This program
serves the kernel but is not in the security kernel. Its
malfunctions can stop the world, but can do no worse.
This chapter {(p1,external)}
commits the kernel to handling an unbounded set of processes.
The kernel is also committed to keeping track of things
whether they be on disk or in core. The kernel is responsible
for remembering more processes than will fit in core. See
(p2,decongtool) about this.
Another level of description that is commonly used
but does not have a name yet excludes the above keys and
also all the keys in (p2,resprim).
In most cases the descriptions of keys are external specifications
only. This means that the level of abstraction excludes
any keys that are closely held by the implementation of
the key.
Much of Gnosis programming consists of defining a key at
one level and implementing it at a lower level.
A functional definition of a key must describe {at some level}
the result of using the key in each of the two ways a key
can be used, namely invoking it and passing it. To describe
invoking a key is straightforward. How do we define the
result of passing the key to all possible keys? We may
not know about all the possible keys.
Note that we can exclude any keys that are excluded by
the level of description.
Instead we assume that each key defines the result
of passing all possible keys to it. Why is this easier?
And does this satisfy the requirements of level of description?