Re: IDL interfaces Robert Wittams (robert.wittams@ic.ac.uk)
Sat, 08 Jul 2000 22:24:57 +0100

I took a bit of time to think about this one...

> ** One object, different interface thinnings
>
> In this pattern, there is a single conceptual object that has a set of
> operations. Different interfaces (represented by different capabilities)
> export different subsets of these operations. Note, however, that the
> operation codes (the number corresponding to the function being invoked) are
> not assigned on a per-interface basis. The read-only interface to a page
> uses the same function number for "read" as the read-write interface; it
> just doesn't export the operations that permit write authority.

Hm - I don't know if this matters overly much. We have to have some way of refusing invocations of random order codes anyway - so surely it would be better to just expose the whole interface and return errors when this happens... but this might be annoying..

> While you could pretend that these are just different objects, this becomes
> rapidly inconvenient. In particular, more powerful interface variants often
> want to return capabilities to less powerful interface variants, and you'ld
> like to be able to type check that fact. It helps to know that the two
> objects are really the same.
>
> I have not yet encountered an IDL input language that makes the expression
> of this natural.

how about introducing a new keyword or two: eg

interface Something : Unknown { 

	void do_something_1(in boolean foo);
	void do_something_2(in boolean bar);
	Something get_sensory();

}

interface SensorySomething thins Something {

restrict do_something_1();
}

> ** Many Objects
>
> The second design pattern is to export both an object and it's metaobject
> from a single process, or several instances of the same object. For example,
> the file system object conceptually exports both a set of filesystem related
> interfaces and also a file interface.
>
> I'm not aware of any special difficulties that this causes.
>
> ** Historical interfaces
>
> An EROS process may start in either of the two design patterns above, and be
> forced to implement variant interfaces over time for reasons of backward
> compatibility. This complicates matters considerably.

Somekind of versioning could be done, but I doubt it would be pretty...

> Finally, mapping the interface to the IPC isn't trivial. Someone (Kragen?)
> has already noted that the manual describes the protocol in terms of what is
> transmitted in R0, R1, etc. rather than what is transmitted in EAX. On each
> architecture there is some physical register corresponding to R0, but you
> should think of this as a last-minute macro-substitution at the bottom-most
> layer of the assembler. The specification of the bottom-level IPC
> representation can be made independent of the target architecture.
>
> Regrettably, the stub generator needs to know the mappings on a
> per-architecture basis, because they overlap. On the x86 in particular,
> registers are so tight that load and spill code must often be generated in
> order to get everything into the right places. This is actually a serious
> deficiency in the IPC spec, and it means that the stub generator is (a) not
> trivial and (b) must target assembler, not C.
>
> In short, it's all rather a serious mess.

Yes. I can't see anyway to make it efficient enough to be the primary communications
method and be easy to generate - but it is best if we keep that nasty stuff in one place - the stub generator.

Also, as long as we follow some clear rules for how we generate a message on each architecture, I think it will be ok.

Eg. Off the top of my head -
The first four word length or smaller data arguments will go in the registers.
Longer data arguments and subsequent word length arguments go in the send data.
The first three key arguments will go in the key registers. If there are only four key arguments, the fourth key will go in the fourth key register. If there are more than four keys, a cappage (or node?) will be requested from the space bank and a key to this will go in the
fourth key register.

Whats wrong with this - how to handle longer than message data arguments (create an address space and pass a key to that? ) And I'm sure it is broken in other ways too.

Other things that need to be thought about:

Rob