Resend: Retiring Returner

Landau, Charles charles.landau@compaq.com
Tue, 10 Nov 1998 16:19:35 -0800


  >I can see no reason why the authority to do these operations should not
be intrinsic to a process.

KeyKOS supported emulation of other operating system environments, such as
Unix, that have no concept of keys. Whatever mechanism you propose to use to
swap keys, that mechanism must do something different in a Unix-personality
process. (In KeyKOS, you could withhold all keys, including the Returner;
any attempt to invoke the returner would trap, and the domain keeper could
do the appropriate emulation.) 

-----Original Message-----
From: Jonathan S. Shapiro [mailto:jsshapiro@earthlink.net]
Sent: Tuesday, May 12, 1998 8:31 AM
To: eros-arch@eros.cis.upenn.edu
Subject: Resend: Retiring Returner


Sorry about the last post -- it was keyed from my palm pilot, and
apparently I had line wrap misconfigured in my desktop mail agent.
Here is the same message, properly wrapped:

I'm considering retiring the returner.

Key permutation can be done significantly faster as an indivisible
supervisor-implememted instruction. I need key load/store instructions
to support capability pages anyway - adding key reg copy/swap
instructions is not a signifiiant addition. I can see no reason why
the authority to do these operations should not be intrinsic to a
process.

String permutation (CALL case) is better handled with a library
routine.

Prompt RETURN/SEND are more efficiently implemented with a mode bit on
the operation. Is there any argument that such prompt operations
should require explicit authority?

Jonathan S. Shapiro
http://www.cis.upenn.edu/~shap

The EROS operating system:
http://www.cis.upenn.edu/~eros