[coyotos-dev] CapIDL design issue -- capability return type

[Jonathan S. Shapiro]

We are updating CapIDL (the IDL compiler for EROS/Coyotos), and some
issues have come up. There are two issues, but they are closely related.
The second concerns capability return values.


Consider the following IDL procedure:

   coyotos_cap_t getReducedCap(coyotos_page page, restrictions_t r);

Unfortunately, that return value isn't really an OUT parameter. It is an
IN parameter. That is: the caller must provide the
"location" (capability register or capability storage location) where
the return value is to be provided. There is no effective way for the
IDL generator to "guess" a location.

There are basically three ways to handle this:

0. If every method returns a result code, then the outcome is similar to
   case [2] below.

1. Add a return cap location to the IDL environment. So we will end
   up with something like the following C call:

      IdlEnv.replyCap = <cap location>;
      cap_t cap = getReducedCap(somePageCap, RESTR_RO, &IdlEnv);

   Note that there is no analogous problem in CORBA IDL, because server
   connections are not first-class types in CORBA IDL.

2. When a method returns a capability, convert the procedure to return
   void and add the capability as an OUT parameter. The IDL above would
   get rewritten to:

     void getReducedCap(coyotos_page page, restrictions_t r,
                        OUT coyotos_cap_t _retVal);

   this is very similar to the rewrite that occurs when the result code
   is universally returned, except that it is done ONLY when the return
   value has capability type.

3. Modify the CapIDL input specification so that it does not allow
   capabilities as return types. The effect of this is that it forces
   the IDL author to do the rewrite explicitly. The main advantage of
   this is that the IDL compiler does not have to introduce new
   parameters, and the correspondence between the IDL declaration and
   the C declaration is directly maintained.

My personal opinion is the following:

  * [3] is preferable to [2]. [3] preserves correspondence between
    IDL input and output, and avoids introducing a rewrite that is only
    sometimes applied (and is therefore confusing).

  * I find [1] confusing and redundant. Since the problem case does not
    arise in normal CORBA IDL, no compatibility concern exists, and
    I therefore consider [3] preferable to [1].

  * [0] is the most consistent outcome (and the easiest to implement),
    but it is source-incompatible with a large body of existing code.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC