Re: If QNX is successful, why NOT GNU Microkernels

[Marcus Brinkmann]

On Wed, Jan 21, 2004 at 04:07:26PM +0100, Olivier Galibert wrote:
> Security is essentially dependant on userspace.  And frankly the linux
> and bsd kernels have been way more reviewed in that area, so I'd trust
> them more.  The security model of the translators in presence of crons
> runs from priviledged accounts with find in them can be interesting in
> particular.

This is indeed a concern, and can be fixed by disabled the translator
mechanism on untrusted nodes by default.  This means that depending on the
owner of the node, you get to see the translator as a translator, or
transparently as the filesystem it provides.  This can be configurable
per-task, with root:$USER as the default (well, you get the idea).

> I've heard a lot of things about Mach, but never that it was well
> designed.  Its task/thread model sucks, its VM model sucks, the
> marshalling/unmarshalling on syscalls is a performance nightmare.

You have to put it into the perspective of OS design history.  The success
of Mach is to show that splitting up a kernel in a generic core part and a
specific server component (or multiple) is possible.  It's only a first
step in a new branch of the still short history of OS design.

Also, you will have a hard time to substantiate your criticism.  I don't say
that your criticism is wrong (in fact, I agree), but "sucks" is an
evaluation that tells us more about you than about Mach :)  If you want to
analyze for example the IPC performance, you will find out that a lot of
research was necessary to find out exactly _why_ it sucked and what can be
done to fix it (and it _can_ be fixed).  I don't say that the burden is on
you to do this.  You can very well lean back and watch if it happens, and
until then you can feel comfortable knowing about the superiority of
existing traditional solutions.

However, this is not a contest.  We are not in competition with anyone in
terms of performance, security, etc.  There is no price to win if we are
better in any category.  We are most interested in exploring the
possibilities of microkernel OS design.  We are interested in exploring its
limitations, too.  But we don't stop at the "it sucks" level.  We try to go
beyond it and point out why it sucks, what can be done to make it not suck.
 
> Hurd itself is better, but still has its problems, the main one being
> the lack of distributed memory caching management.  And it still has
> to cope with the mach annoyances, in particular cthreads.

Indeed one of the major problems with Mach is its centralistic VM system. 
You should be interested to learn that in Hurd on L4, we plan to have tasks
be self-paged, and be provided with physical memory.  Clever protocols will
allow untrusted tasks to share memory and even allows zero-copying from the
device driver directly into an untrusted user's buffer.

Again, this is all "dream land", as you called it.  But you can not even
hope to get there by "accident", or by incremental optimization of a working
traditional solution.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/