[coyotos-dev] IPC Redesign
clandau at macslab.com
Tue May 22 13:30:40 EDT 2007
At 9:38 AM -0400 5/22/07, Jonathan S. Shapiro wrote:
>We are going to revert to a design in which every transfer involves
> exactly 4 capabilities IN/OUT
> a control word IN/OUT
Is the "control word" transmitted to the recipient like a data word
(opcode), or is it consumed by the kernel?
> protected payload OUT
> endpoint ID IN/OUT
> ** up to N data words IN/OUT
> An indirect data string, IN/OUT
> possibly of length 0
>The engineering question is: what should N be?
>In EROS, N was 3.
In EROS, N was 4 if you include the opcode as a data word.
>If we select N=8, the binding above can be implemented in 13 registers
>(max). A message transmitting two payload words, one capability, and no
>strings requires a total of 7 words at the syscall interface, of which 6
>are carried in registers.
>I provisionally believe that N=4 is enough for most real cases. Given
>that IA-32 is not an impediment, AMD64 can handle N=8, and unused data
>words don't cost anything,
If you are passing "up to" N words, don't you need another word to
specify how many words to pass? Or are you packing this into some
other word somewhere (the control word)?
>I am inclined to go with N=8.
I'm approaching this issue from the standpoint of compatibility with
CapROS. It would be a pity if programs written for one system were
difficult to port to the other because they use features that are not
available on the other system.
In CapROS, entry and exit are specified in a single operation such as
CALL. I figure it takes 16 registers to specify all the in and out
parameters where N=8. The ARM architecture has only 13 or 14
More generally, if you make N larger than necessary, you'll be saving
and restoring more registers (or testing N to see how many to save),
which will hurt performance. So I'd vote for making N no larger than
More information about the coyotos-dev