[coyotos-dev] CapIDL design change -- argument rotation

[Jonathan S. Shapiro]

In the current CapIDL implementation, IN and OUT parameters are
re-shuffled. All IN parameters are moved to the left and all OUT
parameters are moved to the right. Order of IN parameters is preserved.
Today, the *return* result is then inserted as the *first* OUT
parameter.

This rotation has almost no effect today, because there are very few OUT
parameters, and people tended to write them in the way described above
in any case.

The reason this was done was to allow me to pick up parameters directly
from the call frame. The theory was that stub procedures would be picked
up from a library, and would therefore form a call frame. The main
DISADVANTAGE to rotation is that IDL methods and C methods do not
directly correspond.

It has since become clear that stub procedures should be inlined. If
stub procedures are inlined, no frame is formed, and there is no
advantage to perturbing argument order.

Therefore, the following changes will be coming in CapIDL in the near
future:

  1. Parameters will no longer be permuted. This will cause source
     incompatibilities exactly if you have an IN parameter that appears
     *after* an OUT parameter in one of your methods.

     Based on a quick perusal, this will not have any terribly broad
     problems.

  2. Client stub procedures will be inlined. This mainly means that no
     library needs to be linked to use them.

The best way to avoid any surprise from these changes is to review your
IDL. Where IN and OUT parameters are currently mixed, gather all IN
paramaters to the left and all OUT parameters to the right. This will
not change the existing stub that is generated in the short term, and it
will remain compatible under the new scheme.

That is: apply the rotation yourself.

As an INTERIM compatibility assist, I will add a diagnostic that
complains when procedures will not transition compatibly.

shap

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC