Unified conceptual framework

The basis for all of our design work was the concept of a set of objects, each of which can be accessed only through a small set of primitives. Any design proposal was implicitly expected to consist of three parts:

i)

an abstractly specified set of states for an object,

ii)

a set of primitive actions on the object and their effects on the states,

iii)

a representation for the states.

The concept of C-list combines and generalizes a concept which appears in many operating systems, that of a list of entities which a process may reference. For example, consider TENEX [T1]. Associated with each job is a list of files which processes within that job may access, while associated with each process is a list of processes which may be referenced. Neither of these lists provides the full power of a C-list, and presumably they are managed by entirely separate system routines. Within CAL TSS, there are no explicit lists of this kind. Rather, they are implicitly represented by the capabilities that appear in the local C-lists of the user subprocesses. Furthermore, associated with each process in TENEX is a set of ``capabilities'' (binary flags) which control which system calls are permissable for the process. The same control in CAL TSS is provided by controlling which operations (accessable only through capabilities) are available to a particular subprocess. This is possible since the only operations available to a subprocess are those in its C-list, and in C-lists accessable to the subprocess.