[coyotos-dev] IDL compatibility

Jonathan S. Shapiro shap at eros-os.com
Tue Jun 19 10:46:04 EDT 2007

On Mon, 2007-06-18 at 16:56 -0700, Charles Landau wrote:
> At 2:15 PM -0400 6/18/07, Jonathan S. Shapiro wrote:
> >For interoperability, the thing we most need to watch out for is that
> >the name mangling strategies of the respective IDL compilers remain
> >compatible.
> What's annoying is that capidl generates exception values that are 
> inconsistent. For example
> package coyotos;
> exception foo;
> and
> package capros;
> exception foo
> generate different values for the exception.

This is not inconsistent. It is *required*. These method declarations
appear in distinct packages. They are distinct exceptions and must be
assigned distinct codes.

> Method codes, for some reason, seem to match.

This is a bug, and it is being repaired. The original intent was that
method codes should be determined cryptographically. The concern was
that a 32-bit order code lent itself to birthday paradoxes if a
system-wide total of 2^16 methods were declared (as seemed likely). I
have subsequently concluded that my concern was excessive, because the
real issue is 2^16 methods in any single chain of inheritance. CapIDL
will shortly switch to cryptographically generated method codes.

Cryptographic code points are regrettable because they cannot be
efficiently demultiplexed. The problem with any *other* method code
synthesis scheme is that central coordination is required to avoid code
point collisions.

The reason that we did not do this for exceptions is that exceptions are
cross-cutting. While method names exist in the context of an interface,
exceptions can propagate widely, and exception names are therefore
effectively global. The current exception code scheme will fail if more
than 2^16 exceptions come to exist system-wide, and I am of the opinion
that exception code values should be increased to 64 bits to avoid this.


More information about the coyotos-dev mailing list