From: Ian King (iking_at_killthewabbit.org)
Date: Mon Jan 12 2004 - 17:26:31 PST
The title of this paper could almost be considered inappropriate, as the authors
discuss an "environment" for the construction of a multiprocessor operating
system, and endeavor to separate architecture from implementation. The fact
that they actually implemented this environment provides for a useful backdrop
to the discussion. It is also noteworthy that the system, C.mmp, was
implemented with "commercial off-the-shelf" hardware, namely a cluster of PDP-11
minicomputers. Having done so, however, the existence of multiple processors is
not emphasized in the remainder of the paper; the principles described herein,
particularly the protection mechanisms, serve the goals of the system regardless
of its platform.
The authors begin by setting forth the design philosophy, and two of these
principles are of particular interest. First, the separation of mechanism and
policy is seen as essential to creation of a flexible system; for instance,
while there should be mechanisms to provide protection of system objects, the
use of those mechanisms, i.e. the security policy, should exist at a higher
system level. Secondly, the authors reject the idea of a strict hierarchy of
functional layers (such as that seen in THE) as also being overly restrictive;
they point out that while hierarchy may be appropriate for some system
functions, it may hamper others. Regarding one other philosophical point called
out: I sense a bit of 'tongue in cheek' in the discussion of integration of the
design with implementation methodology, as the authors explicitly admit to the
design biases that, they argue, cannot help but influence the final product.
The paper discusses the execution environment, and discusses three essential
objects: the process, the procedure and the local naming system (LNS). It is
quite useful to call out the distinction between the process and the procedure,
as a process may execute any arbitrary procedure and, in many operating systems,
semantics exist to do just this (i.e. execute() in UNIX). The LNS is the
context of a particular execution of a procedure in a process, and may grow and
shrink during execution; this concept is akin to the use of stack frames by,
among others, the C language. Then, too, a procedure may implement a template,
which upon a call to the procedure amends the LNS of the caller - possibly
granting broader, yet temporary rights to objects than the caller would
ordinarily possess. This is echoed, in a limited fashion, in the setuid feature
of UNIX.
In discussing system objects and protection mechanisms, this paper discusses the
idea of object type as a mechanism for creating new objects that inherently
possess a certain set of capabilities, and also to create new types based on
existing types. While this idea is familiar to most people through the use of
"object oriented" programming languages, it is intriguing to consider it as a
basic element of the operating system itself. Another familiar mechanism is
that of reference counting for objects, which allows implementation of garbage
collection across the multiprocessor space. The protection mechanism is
premised on the distinct capabilities of various objects; however, rather than
expecting all capabilities to be explicitly contained in all objects, the
authors define a group of type-independent rights, called kernel rights, as
distinct from type-dependent rights, somewhat condescendingly called auxiliary
rights.
The authors' opinion regarding the definition of a "kernel" is clearly set forth
as a tool to "provide facilities for building an operating system". This argues
that a kernel is not an operating system, but rather an operating system is the
services of a kernel together with a set of resources and policies for managing
those resources. Those tools that compose the kernel are the mechanism for the
management. Such a definition suggests a small, lightweight kernel managing a
potentially large but scalable set of resources - a structure seen in some
modern operating systems, most particularly those described as "microkernel"
systems.
The paper concludes with an example of how these mechanisms allow for the
creation of a program and set of data that allows for fine-grained control over
both the executable and data elements of the system.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 17:51:43 PST