[coyotos-dev] IDL compatibility

[Charles Landau]

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 
semantics.

>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
>servers,

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 
functions.

>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:
>
>	com.eros_os.mumble

Or org.ceros_os.mumble.

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
>compatible.

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.