[coyotos-dev] IPC Redesign

[Charles Landau]

At 1:59 PM -0400 5/22/07, Jonathan S. Shapiro wrote:
>On Tue, 2007-05-22 at 10:30 -0700, Charles Landau wrote:
>  > At 9:38 AM -0400 5/22/07, Jonathan S. Shapiro wrote:
>  > >In EROS, N was 3.
>>
>>  In EROS, N was 4 if you include the opcode as a data word.
>
>Yes. Thank you.

At 9:38 AM -0400 5/22/07, Jonathan S. Shapiro wrote:
>This was too small, because we wanted file offsets to
>be 64 bits, and 3 32-bit quantities is insufficient to transfer a 32-bit
>opcode, a 64-bit position, and a 32-bit length.

So, isn't EROS's N=4 sufficient for that? One opcode and three other 
32-bit words.

>  > 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.
>
>This is the job of CapIDL.

Can I use CapIDL to write a transparent forwarder/proxy that will 
accept *any* message? How many data words does my proxy need to 
handle?

>  > 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.
>
>You are assuming that all parameters need to go into registers. This is
>not correct. Only the OUT parameters need to go in registers.

If I understand, that is because the IN (to the kernel) parameters 
are fetched while in the process's own context and address space, 
where handling memory faults is not difficult. The OUT parameters are 
transmitted while in the sender's context, not the recipient's, so 
any parameters in memory would require a cross-space transfer.

>  > 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.
>
>Agreed, but if we make N too small we will be using indirect strings
>frequently, which is extremely expensive. The EROS value was
>demonstrably too small.

See question above.