Re: MIG on L4/hurd?

[Neal H. Walfield]

To date we have been writing required stubs by hand.

Porting MIG may not be overly useful as its nicer features, namely the
port manipulation and memory management don't map well to the
mechanisms in Hurd on L4 port.

When we last evaluated IDL4 (and I don't think it has changed since),
we determined that the inability to guarantee ABI compatibility
between sub-architectures, ABI compatible L4 implementations and IDL4
versions was a serious short-coming.  From our point of view, changing
the message layout is similar to changing from a.out to ELF.  Andreas
Haeberlen explained that ABI compatibility was never an important
goal: IDL4 is an experiment with the goal of finding the maximum IPC
throughput; optimizing for a specific ABI is a different project (but
one not necessarily incompatible with the IDL4 framework).  To use
IDL4 in its current form, we would have to make sure that the server
and client stubs are generated by the same version of IDL4 with the
same flags, etc.

There are a few approachs we can take: modify IDL4 to optimize for a
specific ABI; write our own IDL compiler; adapt an existing IDL
compiler to our needs; or continue to write stubs by hand as needed.
Whatever method we choose, once we make a major release, we are locked
into the ABI for a while or we need to provide ABI versioning (ick!).
Until someone seriously takes up the task of researching and designing
an ABI, I propose the hack with the smallest opportunity cost: writing
the stubs by hand.