Re: MIG->Corba

[Igor Khavkine]

On Wed, Feb 14, 2001 at 03:21:16AM +0100, Farid Hajji wrote:
> > We're talking about a microkernel arch, but still I'm
> > not sure if turning hurd into gnome is a good idea.
> [...]
> > Interoperability is a good idea, but if you bloat the
> > whole code with interoperability stuff then it blows up.
> You can add as much interoperability stuff between apps.
> if you wish. But please keep the overhead to a minimum
> when it comes to hurd servers!!
> 
> 1. Porting the Hurd to non-Mach kernels (L4 is being one of
>    the candidates) would be IMHO easier if the interfaces
>    use plain C and are as simple as possible.
> 
>    The problem here is not the interoperability or adding
>    yet another abstraction layer on top of what is already
>    there. On the contrary: There is currently too much
>    communications overhead already in the ports library.
> 
> I'd humbly suggest that before we seriously consider Corba
> as a MiG replacement, we simplify the existing interfaces
> as much as possible. Trying to port the Hurd to L4 is a
> hard enough task and I'd prefer to have to _simplify_ MIG
> (requirements) and provide an L4 backend to it, rather than
> having to fight with yet more complex interfaces. [Sure,
> L4 has completely different characteristics as Mach, like
> synchroneous IPC and lack of port-rights, so a port to L4
> requires much more work than just adapting MiG, but why
> make it even harder?]

CORBA is not a runtime library, so if you "add CORBA" support
to something does not necessarily mean bloat. CORBA is mainly
a standard to aid in development, I think that's the best
light that IDL could be cast in. If you know that you'll know
that the interfaces you're dealing with are Mach ports (or
whatever L4 uses), you can implement the actual message passing
with inline stubs that use Mach's (or L4's) proper messaging
protocols. Hence no performance is lost, and you've just saved
yourself a whole lot of typing effort. 

Also microkernels do not need to have anything to do with
CORBA at all, infact it would be a mistake to tie the former
with the latter. The best way CORBA can be used is as a
development aid to superimpose uniform interface types on
otherwise very different backends, Mach and L4 for example.

[ snip ]
> 
> 2. The Hurd is intimately tied to glibc (sysdeps/hurd, sysdeps/mach/*)
>    and unthinkable with another libc. If you want to port the Hurd,
>    you _must_ currently also port glibc.

This actually makes perfect sense. Hurd and glibc are part of the
same larger project, GNU. And Hurd was specifically designed
to be integrated with glibc, it didn't happen because of some
fluke or because people were lazy.

Igor