[coyotos-dev] IDL compatibility
clandau at macslab.com
Mon Jun 18 18:39:43 EDT 2007
At 2:15 PM -0400 6/18/07, Jonathan S. Shapiro wrote:
>On Mon, 2007-06-18 at 10:27 -0700, Charles Landau wrote:
>> So, thinking about how you would port a program, say from Coyotos to
>> CapROS, without major rewriting:
> > In cases where methods are identical (and there will be some), you could
>> #include <coyotosCompatibility.h>
>> which contains for example
>> #define coyotos_spacebank_alloc capros_spacebank_alloc
>> (or better, define coyotos_spacebank_alloc as an inline function that
>> calls capros_spacebank_alloc)
>> Is this what you have in mind?
>Not at all. An approach like this is extremely unlikely to work, because
>the interfaces are not the same in most cases.
I said, "In cases where methods are identical", in both interface and
>What seems more likely is that we would simply take your IDL files,
I guess you are changing the example to port in the other direction,
from CapROS to Coyotos. OK.
>compile them to produce the expected stubs (but generated with our IDL
>compiler, therefore using the Coyotos transport mechanism), and then
>implement a simulation of the appropriate interface in the appropriate
I wouldn't expect you to change your servers to add CapROS
compatibility, at least not until CapROS becomes wildly popular ;-).
>or in front ends.
As I understand capidl (which is not very well), it generates a stub
to invoke a capability (as you implied when you mentioned the Coyotos
transport mechanism above). So the front end must be an object
invoked via a capability, which adds a context switch or two.
In many cases the simulation can be handled in a library instead of a
separate object. In such cases (reread that - IN SUCH CASES, not in
all cases), instead of generating Coyotos stubs and writing a front
end object, you could just write library procedures. There is room
for both approaches.
I can see the advantage in using generated headers for supporting
various languages. For that you give up the ability to use C inline
>However, I should make something clear about the model of interface
>naming in the Coyotos tree. The "coyotos." package will be used only for
>the kernel and the core domains. Other domains (and hopefully most user
>domains) will be built following the Java model, where the package name
>becomes something like:
Why do your kernel and core domains not use the Java model?
>For interoperability, the thing we most need to watch out for is that
>the name mangling strategies of the respective IDL compilers remain
I don't see any reason for them to diverge. But if they did, you
could continue to compile with the CapROS IDL headers, and simulation
code written as a library would be able to bridge the differences.
More information about the coyotos-dev