[coyotos-dev] IPC Redesign

[Charles Landau]

At 3:03 PM -0400 5/22/07, Jonathan S. Shapiro wrote:
>On Tue, 2007-05-22 at 11:22 -0700, Charles Landau wrote:
>  > 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.

The length requested could be "spilled", that is, sent in the data 
string, which is otherwise unused.

I'll save Shap the trouble of responding that this increases the cost 
of the call. But it's a very small cost.

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

Looking at the code at 
http://www.opencm.org/opencm/~/PUBLIC/EROS/DEV/eros/top/src/base/domain/nfile/nfile.c, 
it does not appear that write was a problem. The length to write is 
the length of data sent.