Re: If QNX is successful, why NOT GNU Microkernels

[Olivier Galibert]

[comparing essentially with linux 2.6 here because it's state-of-the-art
 and the one I know best]

On Thu, Jan 22, 2004 at 01:10:43AM +0100, Marcus Brinkmann wrote:
> 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.

Sure.  It was interesting at the time, no doubt about it.  But it
stopped evolving 10 years ago, and OS engineering didn't.  And, as you
very well know, having in 2004 a multiserver OS based on a 1990 mach
version, and 1990 mach concepts, just doesn't work out.


> 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 :)

"sucks" was just a shortcut for "considered obsolete by current
standards when compared to the semantics and performance provided by
modern systems".


> 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).

Is the why anything else than the cost of the minimum of two VM
switches per exchange with a server plus the small amount of inter-VM
copying needed?  Which is a large, incompressible cost in the ports
model.  The marshalling/unmarshalling cost on top is just gravy.  What
were they smoking?

Fixing it must be fun though, I'll have to look up the proposed
solutions.  Comparing with the linux syscall speeds will be _tough_.


> 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.

The solutions I consider superior are hardly considered traditional.
The trend for thread/process unification is reasonably recent, and the
recognition of the value of a clone-like syscall where you create a
new scheduler object and cherry-pick what you want to share isn't very
old either.  Or the futex approach to locking.  Or the O(1)
scheduling.  Or the full memory cache unification.  They appeared a
while ago in various oses (BSD, plan9...), but they're understood as
the Right Way[tm] to do things for max 5 years.

You'll notice btw that what I cite is not incompatible with a
microkernel approach (well, the cache unification may be hard).  It's
Mach itself I consider badly designed by today standards, not the
microkernel concept per se.


> 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.

What you win, or nowadays lose, is volunteer developpers.  Imagine
someone new who wants to play with OSes and trying to find out what
Hurd should eventually have that the others don't have.  The gnu.org
Hurd page is pityful in that aspect, all the features it cites are
covered by current monolithic kernels.  The Hurd on L4 page boils down
to "L4 is better than Mach" (well _duh_), and half its "Related item"
links are dead.

If the developper digs deeper, the only thing he'll find is the
translators, which can be seen as a combination of triggers (soon
coming as "mount traps" on linux, only missing the persistence at
filesystem level) and userland filesystems (already existing).  And
that's it.  Nothing else potentially interesting is ever cited.

So, well, if it's only to redo what already exists and with less
hardware support, he may not be very motivated...


> 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.

Sounds cool.


> 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.

Dream land was about userspace drivers miraculously making the system
more stable.  Zero-copy to/from userspace is so not dream land that
it's already supported in linux.

  OG.