[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: If QNX is successful, why NOT GNU Microkernels

From: Marcus Brinkmann
Subject: Re: If QNX is successful, why NOT GNU Microkernels
Date: Thu, 22 Jan 2004 00:56:47 +0100
User-agent: Mutt/1.5.4i

On Wed, Jan 21, 2004 at 01:27:53PM +0100, Olivier Galibert wrote:
> [1] streaming on syscalls, no cache management, heavy tasks, cthreads,
>     heavy locks...

There are certainly some issues within that scope, like cache management,
which however _must_ be solved radically different in the Hurd design than
in a monolithic kernel, simply because of what part of the system has what
responsibility and which information to make good decisions.  There are good
indications that if the design we have in mind would be implemented fully
that you can actually optimize programs beyond what you can achieve in a
general purpose monolithic kernel model.

But please note that tasks are _always_ heavy, and cthreads is just an
obsolete interface (pthread is sort-of available, and there is no particular
reason why Ulrich Drepper's pthread can't be ported).  Heavy locks, if that
refers to futex's in the kernel, then that's certainly something you would
never see in the Hurd because of design paradigms.  But it is not at all
obvious that this is a hard reason for anything.  Locks can be maintained
locally in a task, shared locks with support with a trusted system service,
and if you really need scheduler magic for maximum efficiency, then that
could be an interesting research topic.

> [2] follow what a simple read() in a C program has to do before it
>     returns with the results and cry

If that makes you cry, then open() would probably kill you.  But you should
have learned very early that read() is a slow way to read from files.  If
you use fread, then that can make use of optimization (for example: zero
copy I/O in 4 MB superpages for sequential read).

It's one thing to beat on the current implementation, which is still a very
good proof of concept.  It's another to really understand what the important
problems are and what can be done to fix this without falling back into
traditional paradigms of Unix kernel programming.  You have barely scratched
the surface.  After the initial shock you hopefully will see things shift
back into perspective, and if you are interested in these topics you will
find that each topic you mentioned (and many more) opens the door to endless
alternatives in the design.

Some people claim that Mach proved that a microkernel system is not
feasible, and the obvious failure plus the continued succeess of monolithic
unix kernels supports them in thinking that this is the best way.  We say
however that the microkernel experiment has just started with Mach, and that
it just opened the door to a rich world in OS design, which is still
unexplored.  This is of course all vapor and hype until the real thing
proves the opposite.  Still, I challenge you to read hour hurd-l4 design
docs and tell us in which area we will have intrinsic disadvantages in areas
that matter compared with monolithical kernels.  


`Rhubarb is no Egyptian god.' GNU
Marcus Brinkmann              The Hurd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]