From: Ian King (iking_at_killthewabbit.org)
Date: Mon Jan 12 2004 - 16:49:19 PST
Dennis and Van Horn's paper describes semantics for discussing securable
multiprogrammed systems. While they have attempted to create their lexicon at a
very high level of abstraction, many of the concepts discussed can be traced
directly into known implementations - which speaks well for the abstraction.
Those concepts are also seen in other literature of the immediately subsequent
era.
The concept of a segment as a fundamental unit is described; it is interesting
that the authors admit it is implemented as a 'file' in at least one extant
system. The word is unfortunate, because to modern ears it tends to conjure the
idea of a memory segment. However, it is clear that a segment has no fixed
physical reality, and can appear in dynamic memory or persistent storage. Its
true significance as a concept is in the context of security.
While the paper briefly discusses the idea of multiple processors, there is no
discussion of the mechanisms by which multiprocessor systems would share the
physical resources - that's a hardware problem. It is also interesting that the
authors expressly state that the significance of ensuring parallel execution of
processes is for efficiency of resource allocation, not performance. This is a
reminder of the scarcity of resources in a typical computing system of the day.
One concept that remains quite abstract is that of a capability. I admit to
having difficulty grasping the true import of this concept until reading a
subsequent paper in which it was employed at a slighly more concrete level. The
C-list is also quite abstract, and I believe is usually implemented implicitly,
and sometimes in hardware structures. For instance, the ability to access
physical memory is constrained by virtual memory systems, which are supported by
physical memory managers that enable the mapping between physical and virtual
spaces; this mapping is not only done to create large virtual memory spaces, but
more importantly to provide protection of one process' memory from another - to
enforce the implicit granting of capabilities to one process, and denial to
another.
The idea of inferior spheres of protection is introduced as a debugging aid, but
it is arguable that this is the model employed by many operating systems to
distinguish between user processes and system processes; while some systems
implement a 'supervisor' as a distinct, superior entity (or segment), others
implement the supervisor as a process distinguished only by its capabilities.
The concept of protected entry points is interesting, as this is the method
employed by the Windows CE operating system to implement system calls. Other
operating systems employ some sort of exception (or "trap") mechanism to convey
requests into a privileged supervisor.
The discussion of exceptional conditions is well considered and presents a
reasonably complete taxonomy.
Naming and directories read quite easily to one familiar with modern systems.
The problem of ambiguous names, which the authors suggest can most easily be
addressed with a required prefix. This solution has been implemented by some
operating systems through automatic addition of distinguishing information (for
instance, the user ID as part of the file name in RSX-11), but is most commonly
implemented today through the inclusion of a hierarchical directory name string,
or path, as a logical component of the file name.
As always, the culture in which the authors worked comes through in their
writing, and it is interesting to note the interest in accounting for use of
computational resources. While this concept is not familiar to those who have
worked exclusively in the personal computer world, it was pervasive in a time
when hardware was incredibly expensive and amortizing that cost was a key goal
of most computers' keepers.
This archive was generated by hypermail 2.1.6 : Mon Jan 12 2004 - 16:51:27 PST