[coyotos-dev] IPC Redesign

[Jonathan S. Shapiro]

On Tue, 2007-05-22 at 11:22 -0700, Charles Landau wrote:
> 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.

The answer is: no, it wasn't. But that isn't obvious because I left out
an argument above. I believe that the problem case was efficient
implementation of POSIX-style read64() in a UNIX emulator. The operands
required are:

   opcode  32-bits
   fd      32-bits
   offset  64-bits
   length  32-bits

This exceeds 4 words. The underlying problem is that in the absence of
the length parameter you don't know what was sent (as opposed to
received) if the read returns a short result.

Also, my memory may be playing tricks on me -- the real issue may have
been in write() rather than read(). In any case, I distinctly recall
that one of these cases did not work out.
   
> >  > 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?

No. CapIDL *explicitly* does not expose low-level representation. That
isn't its job. The entire point of CapIDL is to isolate the user from
the low-level representation. The policy decision is that interfaces are
defined by their IDL, not by their transport-level protocol.

Setting that aside, fully transparent forwarding is not possible in
principle, because you need to know what the call/response protocol is,
and you can only know that if you are able to interpret the higher level
session setup protocol. The problem here is not in the re-transmission
of messages. The problem lies in understanding how to go about
interposing the protocol in both (or most generally: N) directions. That
requires protocol-specific knowledge, and once you require
protocol-specific knowledge the argument that you need a protocol
independent forwarding begins to decay rapidly.

Setting that aside, the proper question is can you do a transparent
forwarder for the CALL/RETURN or simple SEND case if the forwarder groks
the transport layer interface. The answer in EROS is yes. The answer in
Coyotos is "not if the scatter/gather unit is used".

The problem is that the scatter/gather specification mechanism supports
many variants, and the transport does not support any single receive
specification that is capable of receiving all possible transmit
specifications. I shall see if I can rectify that. I suspect that it is
possible. *Assuming* that it is rectified, the amount of storage
required is O(60 Mbytes).

All that being said, my view is that the adoption of IDL strongly
reduces the importance of this issue. Given an IDL specification, it is
possible to automatically generate a forwarder for any given interface.

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

Yes. And Kauer's technique is able to extend this to further out
parameters up to a known bound.


shap