From: Reid Wilkes (reidw_at_microsoft.com)
Date: Wed Jan 14 2004 - 15:42:50 PST
The HYDRA paper is to me one of the most interesting we have read thus
far. I think this is largely due to the fact that it prevents some quite
unfamiliar and novel concepts, while at the same time seeming to make
the concepts much clearer than some of the of the other papers (such as
the "Programming Semantics" paper). The basic purpose of the paper is to
define an abstract infrastructure for building an OS. This
infrastructure provides a couple of significant services: an
object-oriented model for use in building OS services, and a system of
protection developed around these objects. Although the paper supposedly
defines the kernel of an operating system, I have trouble seeing how the
system proposed really could be called a kernel. Rather, it appears that
HYDRA proposes a model for building a kernel. The only thing that HYDRA
paper proposes that is concrete is the protection mechanism around the
objects. The paper makes no attempt to explain how HYDRA might
handle/provide basic OS services such as memory management, file system,
or scheduling. Rather, the paper supposes that all of these things can
be built by "users" on top of the primitive object notions which HYDRA
provides. (clearly they are assuming that "users" are advanced systems
engineers). Early in the paper, the authors make the claim that strict
hierarchical design is not adequate or appropriate for operating system
architecture. The design of the HYDRA system clearly reflects this bias
- the core of the system itself is simply the set of primitive blocks
upon which to build a set of services which essentially are cooperating
peers. The protection mechanism described in the paper is a capabilities
based system, and the authors state that those ideas came directly from
the "Programming Semantics" paper. The discussion of the capabilities
system seems a bit more concrete in this paper and was overall easier to
understand. However, it is still difficult to really get a grasp overall
of how the capabilities system would be applied in a large scale system
(more than the simple examples offered in the papers). One very
interesting thing in the paper is the idea that a procedure itself is
represented by an object and therefore an associated list of
capabilities. This means that a caller does not have to necessarily have
all the permissions necessary to perform the tasks which the method
being called needs to perform. This mechanism provided through a
capabilities based system is impossible to implement with resource-based
access control lists, and closely resembles some of the basic ideas in
the Microsoft .NET Code Access Security system.
This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 15:42:52 PST