Re: Why GNU Mach is so different?

[Jeroen Dekkers]

On Sun, Dec 30, 2001 at 04:09:57PM +0100, Farid Hajji wrote:
> > Others thoughts that I had, are about the Corba (I read something and 
> > nothing more), modules for devices drives (like linux); those things are 
> > better implemented on kernel or is possible on user space?
> 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.

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.

> The dream of uKernel developers is of course to move device
> drivers outside the ukernel. The idea is to have user-land
> device driver tasks that will serve interrupts etc... on
> the one side and requests from an OS entity on the other side.
> 
> You _can_ write device drivers in userland, both for Mach and
> for L4 (it's easier for L4).

It's not only easier for L4, it's also the only way. It's not possible
to have kernel-space drivers and IMHO that's good thing.

> The point is not, that you can
> do so, but if you could cannibalize e.g. the large Linux
> driver codebase. One effort to do this was the OSKit which
> you should really examine more closly. The OSKit is being
> used both in the oskit-mach effort as well as in the L4
> community. Another approach is (still-to-be-released) L4Env
> environment, where it should be possible to drop the source
> code of Linux drivers into a framework so that it integrates
> in the L4 user-land tasks.

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.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects.net

pgpUGHc53EIEz.pgp
Description: PGP signature