bug-hurd
[Top][All Lists]
Advanced

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

Re: adding system calls to an object based system


From: Neal H. Walfield
Subject: Re: adding system calls to an object based system
Date: Wed, 25 Jan 2006 21:25:07 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 25 Jan 2006 16:34:14 -0300,
Leonardo Pereira wrote:
> As I know, those interfaces already exists.

Gianluca's proposal is to expose these interfaces directly at the
syscall level.  Currently, the mechanisms are available via the
appropriate device object.

> So, I didn't understoo your "we
> shouldn't add such interfaces to Mach". I do not understand why someone
> would like to use IPC if we have an alternative that is faster than IPC.
> This is not related to a good or bad IPC, but the use of good
> mechanisms.

The sole motivation should not be performance.  One of the advantages
of an object-based system is that inter-object dependencies must be
made explicit.  This makes object relationships clearer and in doing
so reduces, in my experience, the number of inter-object dependencies.
The net result is, hopefully, a decrease in complexity and an increase
in robustness.

To achieve this, I think a microkernel should strive to have a single
system call, namely, IPC.  Everything else should be built as an
object on top of that to which users invoke a capability naming the
object.  That an object happens to be implemented by the kernel is
irrelevant.

That the IPC implementation is slow is, I agree, a problem.  This
problem should be fixed at the IPC level or shown that this cannot be
done in a general way.  Fixing Mach IPC will prove difficult: it works
well when memory is near CPU speed.  L4 and EROS have shown that this
result need not be a categorical rejection of IPC based systems:
different IPC models can be fast.

Thanks,
Neal




reply via email to

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