[coyotos-dev] IPC Redesign

Charles Landau 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.
>
>Reactions?

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 
registers available.

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 
necessary.


More information about the coyotos-dev mailing list