[coyotos-dev] IDL compatibility

[Jonathan S. Shapiro]

On Mon, 2007-06-18 at 15:39 -0700, Charles Landau wrote:
> At 2:15 PM -0400 6/18/07, Jonathan S. Shapiro wrote:
> >On Mon, 2007-06-18 at 10:27 -0700, Charles Landau wrote:
> >
> >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.

The entire interface would have to be identical in order for this
approach to work, and the approach seems very prone to maintenance
errors.

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

Sorry. I had not understood which way you were going. Since we seem to
be having a capros->coyotos conversation, let's stick with that, but the
issues are the same in either direction.

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

That depends on the service. There is certainly a range of possible
implementations. One is to use a front-end domain. A second is to add
support for the Capros interfaces into the existing Coyotos objects
[aside: I am *very* happy that you seem to be adopting GPTs, since
reconciling Node behavior in a compatibility layer seems likely to be
difficult.] A third is to let CapIDL generate the headers and then
implement a set of translation functions as a library.

Any of these could work. Which strategy to choose probably depends on
the case at hand.

> 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 agree. I would probably use CapIDL to generate the headers in this
case, however, as you mention.

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

That isn't clear.

At present, CapIDL does not generate inline stubs. This is because the
kernel interface is still in flux, and we don't want to commit ourselves
to backwards compatibility in the kernel itself.

Eventually, it will become appropriate to generate many stubs in-line.
At that point, we will probably stick the implementations in a separate
file that is #include'd by the header file. Once we have a convention
for such a #include, I think it could be used for library compatibility
implementations as well. The problem will be deciding which functions to
declare which way, because there is a forward declaration problem in C
that needs to get dealt with.

The most likely solution is that we would adapt the EROS IDL file to
annotate certain methods as "not to be generated by CapIDL" (there is
already a keyword for this), and we would probably augment the CapIDL
syntax to allow explicit inline annotation in such cases.

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

Indeed.

> Why do your kernel and core domains not use the Java model?

Good question. It probably should, and we will probably revisit that. I
think the main reason was method name length, which was not a good
reason to break convention.

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

They have already diverged, because we fixed a bug (there was a place
where the name wasn't being emitted correctly). However, you will want
to fix the same bug, so I don't anticipate any major mess from that.

shap