large messages

[William S. Frantz]

> 
> >  >How is larger-than-4K message transfer generally done in KeyKOS
> >  >between a client and a server that doesn't want to trust the client's
> >  >promptness?
> >
> >A shared server domain wouldn't do a ping-pong transfer directly. It
> >would create a domain to do this, using the factory mechanism or
> >equivalent. It creates the domain using client-supplied resources. That
> >is why it is necessary to pass a meter and one or two space banks on the
> >very first call.
> 
> Does the meter have to be one that is guaranteed not to run out
> at an arbitrary point and stay dry forever, or can it be just any meter?

The server's per-client domain can use any meter (with no specific 
guarantees) unless it holds a lock which will block other clients.
If it needs to hold such a lock, it can/should run in the server's
meter.  Generally, you can have it run on the client's meter.

 
> How commonly are two space banks needed?  I heard mentioned previously
> that one must be trusted, but the other does not have to be.  What exctly
> does "trusted" mean in this context?  That resources allocated from
> that space bank can't be arbitrarily revoked by the client or someone else?
> And/or that the pages and nodes allocated will not be accessible by anyone
> except the server?  (Or is the latter a general property of space banks?)

In one sense, a space bank is anything the follows the calling 
conventions of the space bank protocol.  It doesn't have to hand
out the only copy of page/node keys etc.  Many programs will require
the second bank to be "offical".  This means it will hand out the
only copy of page/node keys (amoung other things).  However it does
not have to do so promptly.  (e.g. If it runs out of space, it can
ask a user to delete some objects to free space).  The factory
requires the first bank to be both "prompt" and "offical".  (If it
isn't, then the factory doesn't build the object.)  An object called
the Space Bank Transformer certifies "offical" and "prompt".  (It has
been suggested that space banks should be able to certify each other.)

 
> BTW, what exactly is 'KT'?  :-)

KT is the smallest negative number == X'8000000'.


> Also, it would be very helpful to me if someone could post a short
> description of the actual register conventions used for invoking
> the primitive kernel messaging operations, on both the i386 and 88000
> if possible.  I'm still trying to get a clear picture of the exact
> semantics of KeyKOS message passing...

I think I can do best (from memory) with the 370 conventions.  The 88K
is similar (different register assignments etc.)  Jonethan will have
to answer for EROS as that is the closest to a KeyKOS port to that
architecture.

R0 - Exit Block (what the invoker is sending)
  mmmm srxx kkkk 0000 1111 2222 3333 4444
  mmmm is a mask of offered keys. 1==use key in designated slot
                                  0==pass a zero data key
  s==1 a data string is being passed, s==0 no data string
  r==1 the data string is in the registers, r==0 in memory
  xx - must be zero on 370, jump type (call, fork, return) on 88K
  kkkk - slot holding invoked key
  0000 must be zero
  1111 slot number holding first key to be passed
  2222, 3333, 4444 etc.
R1 - 32 bit order code
R2 - address of string (or offset from 1st byte or R0 for register string)
R3 - length of string passed
R4 - address to receive string (or offset for register)
R5 - Maximum length to receive
F2 - Entry block (what you want back) (in a floating point register!?!)
  mmmm srol 0000 0000 1111 2222 3333 4444
  mmmm is a mask of which keys you wish to receive
  s - wish to receive the string
  r - wish to receive it in the registers
  o - wish to receive the order (return) code (if this bit is 0, and the
      order/return code is non-zero then the domain will trap.)
  l - wish to receive the accual string length in R3
  1111 - 4444 slot number to receive keys into

-----------------------------------------------------------------
Bill Frantz                   Periwinkle  --  Computer Consulting
(408)356-8506                 16345 Englewood Ave.
frantz@netcom.com             Los Gatos, CA 95032, USA