From: Gail Rahn (grahn_at_cs.washington.edu)
Date: Fri Jan 16 2004 - 08:26:21 PST
(Sorry it's late, I have had the flu.)
Wulf et al's HYDRA paper describes an object-oriented kernal for operating
systems developed in the 1970s at CMU. HYDRA is a kernel for building
operating systems - i.e. HYDRA is a toolkit, desired operating system
technology is implemented on top of it. HYDRA's design goals included
implementing a set of system features that are "universally applicable" to
any proposed operating system. These features are the set that comprise the
kernel.
I was interested to read that on at least two occasions, the HYDRA team
embraced software design principles that are the opposite of my own. First,
the HYDRA team "rejects the notion of strict hierarchical layering". They
suggest that when enforcing a strict hierarchy, flexibility and
experimentation are severly limited. I interpret this idea to mean that
kernel components don't necessarily have a consistent, closed interface.
Maybe my interpretation is too simplistic, but while rejecting hierarchy
encourages fiddling around with software, it doesn't support other design
principles like re-use. In my opinion, fixed interfaces and layer
relationships can only simplify complex systems. They also ease incurred
development costs because of increased testability.
Second, the team elected to "integrate the design with the implementation
methodology". They believe in the impossibility of separating the design
with the methodology used to implement the design. Again, maybe I'm
applying this idea to objects much simpler than those that compose an OS
kernel, but in my own software development, I've found the strict separation
between object design and implementation to be crucial to portability,
re-use and easy upgrading of object functionality.
The HYDRA project takes the view that the main purpose of an OS is to
provide and allocate system resources. To support that end, they abstracted
the notion of a system resource to be an object. The process, an atomic unit
of execution, is introduced, along with a concept of the context in which a
process is run, as an "execution domain". HYDRA implemented basic protection
mechanisms, gating the access of a process to objects. The set of a
process's access rights (or capabilities) are summarized in its LNS, or
"local name space".
An important distinction here is that the HYDRA kernel provides mechanism
functionality for managing process capabilities but NOT the policy meaning
or implementation of the capabilities themselves. That is up to the OS
designer that is wrapping HYDRA.
In many ways, HYDRA is a step forward from designs summarized in previous
papers for this class. HYDRA provides a generalized, object-oriented view of
the world. THis design increases flexibility and allows for implementation
of arbitrary system resources. HYDRA rejects naming-based object access.
HYDRA separates mechanism from policy - in terms of protection, this means
that HYDRA provides the functionality, and OS designers provide the specific
interpretation of object access or denial. (This strict separation of
implementation and policy seems tense when compared with the "integration of
design with implementation methodology" - seems like they are simultaneously
advocating for design goals of strict separation and strict integration.)
-------------
Gail Rahn
grahn_at_cs.washington.edu
This archive was generated by hypermail 2.1.6 : Fri Jan 16 2004 - 08:35:50 PST