Re: Why GNU Mach is so different?

[Farid Hajji]

> > Regarding CORBA: The only part of it that we'll need in the Hurd
> > right now, is a good IDL stub generator that could replace MIG.
> > The path right now looks like we're needing to switch to flick
> > IDL compiler and change the *.defs with *.idl(s). Then, we could
> > use e.g. DICE or IDL4 to generate stubs for L4 instead of Mach.
> > Other CORBA stuff looks currently like unnecessary overhead to me.
> 
> It's only not a simple thing. First the .defs are really mach-specific
> and MiG does a lot of things with ports we have to implement in the
> servers if we're going to use CORBA IDL.
Yes, that is exactly the problem. _Should_ we implement or duplicate
MiG functionality into a stub generator that is designed to generate
code for non-Mach systems? I'd prefer that we revisit the dependency
of the Hurd code (especially libports) of those MiGisms. This would
also contribute to boost performance, since most IPC would then be
synchroneous (this is just a guess) and would therefore require less
context switches.

> Second the IDL compilers are a problem. MiG is no option. Flick has a
> few problems (I copypast from the manual):
> * Thread Safety: Flick does not generate thread-safe code. If your
> application is multithreaded, you will need to provide explicit locks
> around the Flick-generated stubs.
> * Error Handling: Although the generated stubs generally handle errors
> in an appropriate manner, Flick's runtimes may fail an assert or exit
> in response to certain critical errors. A future release of Flick will
> better address error handling and recovery within the runtimes.
> * MIG language: The MIG front end/presentation generator is nearly
> complete but does not yet support all of the MIGisms you may love (or
> hate).
> 
> DICE and IDL4 are not available yet. However there is going to be some
> pressure to release IDL4, more on that later.
DICE is available, but doesn't generate stubs for Mach at the moment.
So it's not a real option while porting. IDL4 is expected to be released
any time soon.

Flick does have its drawbacks; there's no doubt about it. However,
the main advantage of flick (1.x) at the moment is, that it can
generate Mach stubs and L4 stubs. This is really important at this
moment. Once the transition to IDL is complete, we could always use
other IDL compilers that are better suited to Mach and L4 environments.
The biggest challange right now would be to migrate the Hurd to synch.
IDLs and drop MiG.

BTW, if there are some specific problems with the flick stubs,
why not fix them?

> L4Env is almost the same as OSKit, I don't see what's special about
> it. For me it looks like they are writing an L4 specific OSKit. I'm
> also a little bit more critical about the "drop the source code into
> the framework and it works" part. I don't think it's that simple, but
> maybe I just don't know enough about Linux and L4 drivers.
As long as L4Env is not released, we're just speculating here. You may
be right here. We just don't know.

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.