IDL interfaces

[Jonathan S. Shapiro]

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

No no. If I have a capability that authorizes me to utter that order code,
then it shouldn't be refused.

In KeyKOS/EROS, start capabilities (the ones that invoke programs) carry an
unforgeable 16-bit field that can be used to determine which interface has
been invoked. Either the order code is supported by that interface or it is
considered illegal. There isn't a third option.

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

Nope. What goes in registers should be dictated by how the receiving code
intends to process the arguments. The low-level interface description is
written by the developer anyway, and the IDL compiler is perfectly capable
of getting the right things into the right registers.

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

Stub code should NEVER do this, because it must not be assumed that the
process has access to a space bank at all. If the interface requires a
capage, it should require a capage as part of the interface spec.

No hidden magic! Just get the bits to the right places.

shap