Summary comparison table: COPY/REVOCABLE-COPY

[Jonathan S. Shapiro]

While writing a private reply to Matthieu, I came up with the following
summary table. It seems like it might be useful to others too:

  COPY

                           L4     EROS/Coyotos  Notes
  Primitive?               No     Yes           [1,4]
  Requires Kernel Alloc?   Yes    No            [2,5]

  REVOCABLE COPY

                           L4     EROS/Coyotos  Notes
  Primitive?               Yes    No            [1,6]
  Delegatable revocation?  No     Yes           [3]
  Requires Kernel Alloc?   Yes    No            [2]
  Survives sender exit?    No     Possibly      [7]

  FREQUENCY OF OPERATION in HURD:
    Copy:           common case, probably high frequency
    Revocable Copy: exceptional case, probably very low frequency

  [1] A non-primitive implementation requires more IPCs to implement.
  [2] Allocation accounted to the kernel is a denial of resource
      opportunity.
  [3] Test; If I perform a revocable copy, can I delegate to some
      other process the authority to revoke?
  [4] Espen Skoglund says this could be changed for L4, but the Dresden
      group committed to this at one point and subsequently backed out.
  [5] L4sec is exploring a kernel heap design. If this design is viable,
      then the "requires kernel alloc" answer would change to "no" for
      L4sec
  [6] L4sec is exploring a kernel heap design. If this design is viable,
      then the "primitive" answer would change to "yes" for 
      EROS/Coyotos.
  [7] In EROS/Coyotos, survival depends on life of storage source,
      not life of instantiator or transmitter.