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.
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
