Hydra: The kernel of a Multiprocessor Operating System
 ======================================================
 Wulf et al, 1974.


 Summary:  Describes the design philosophy of Hydra, a kernel for
           multiprocessors in early 70's.  The paper makes a case for
           using objects and capabilities for modular OS design.


 Design Guidelines
 -----------------

 The goal is to maximize "flexibility".  Dont let anything in the kernel
 limit design choices for users of the kernel. Key design guidelines:

   1 Towards a microkernel?

        Provide a core set of functions letting multiple execution
        environments co-exist. Limit this set to the bare minimum necessary
        to let users enjoy maximum flexibility.

   2 Separate mechanism from policy:

        Increases flexibility.  Example: protection requires mechanisms
        while security entails policy decisions.

   3 Dont adhere to THE-style strict hierarchical layering:

        Layering limits flexibility.

   4 Protection:

        Crucial. Should apply to *everything*. Paper argues that
        flexibility and protection are not negatively correlated.
        [Is this true?]


 Design of Hydra's Execution Environment
 ---------------------------------------

 In line with the aforementioned design guidelines, Hydra advocates
 the use of objects, capabilities and protection.

 An object represents a resource. It has a type, a unique name, and
 a physical representation (data part and capability part).

 A capability is a reference to an object along with a set of rights to certain
 operations on the object. Capabilities are unforgeable (kernel controlled).

 The capability part within an object is a set of references to other
 objects that are "visible" to this object.  The transitive closure
 of such references is the set of all objects this object can manipulate
 (subject to the rights contained in the capabilities).

 Dereferencing capabilities requires the mediation of the kernel. Such
 dereferencing takes place only when procedures are CALLed, whence the kernel
 checks that the callee has the requisite rights. This is explained
 in detail below.
 
 Hydra has three basic object types:

 1. Procedure:
      A function with code and data; may accept parameters; may return
      data.  May also contain a list of capabilities to other objects.
      Some capabilities are caller-dependant. These are
      acquired from parameters passed to the procedure by the caller.

      To allow parameter passing, Hydra uses what it calls "templates".
      There is one template per argument to a procedure.
      A template consists of a type-attribute, a check-rights field,
      and a regular-rights field.  The type-attribute is used to enforce
      strict type-checking of the argument object.  The check-rights field
      contains a list of rights which the argument object must possess.
      If the argument has adequate rights, a new capability is created in
      the LNS that points to the argument object.. But (here is the
      interesting part), the rights list of this capability is set to the
      the regular-rights field of the template. This means that a callee
      might have greater freedom to manipulate this object!  These rights
      are available only to the callee; not the caller.

 2. LNS (Local Name Space):
      Corresponds to an invocation of a procedure, with the arguments
      to the procedure (caller-dependant capabilities) bound to the
      parameters of that procedure. This is pretty-much like a stack-frame,
      one per procedure invocation.

 3. Process:
      The stack of LNS's constituting the current "state".  Very much like
      a process on unix.

 In a nutshell, Hydra is all about building modular OS's using objects
 and capabilities as primitives.

 ----------------------------------------------------------------------------
 Notes:

 -  The word "multiprocessor" in the paper title is misleading. There is
    hardly anything specific to multiprocessor OS's in the paper.

 -  There is no mention of a real implementation.

 -  Too few examples to illustrate their design philosophy.
    Perhaps the intent is to allow "flexible interpretation" of their ideas! :)