[Top][All Lists]

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

Re: Hurd IPC

From: Neal H. Walfield
Subject: Re: Hurd IPC
Date: 15 Oct 2002 09:20:35 -0400
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2

> So, with such an architecture, no information about communication channels
> need to be held by the kernel, nor even by one server.


> Nothing special. I don't know if it is a desired functionnality. I
> just wanted to point out that in case it was needed, it should be
> possible to implement it in a generic way on top of any microkernel
> -- on Mach, this implies that we should not use the facility
> provided by the kernel. The goal is, as Marcus stated, to be able to
> have the same the same client and server code whatever the kernel
> is, i.e. the least micro-kernel dependent code.

I do not with this.  We certainly want to be microkernel independent
but that does not mean that we should not take advantage of the
primitives provided by any particular.  I want to stress that the
*implementation* of the Hurd IPC interface is not terribly important;
it is the interface which we need to be consistent: using microkernel
specific features can easily be hidden using some type of sysdeps
structure as found in, e.g. glibc.

> The problem is that on Mach, unlike on the Hurd for Fluke or L4, we use
> "ports", which are a kernel built-in facility. My point of view is that we
> should try to ignore these built-in facilities and use Mach as if it were a
> second-generation microkernel. For instance, we should not use mach_port_t
> directly. Instead, we could implement the mechanism you described, where
> servers are able to manage themselves the handles they deliver.  However, at
> some point, these handles have to be bound to a port since this is the only
> communication mechanism offered by Mach.

Define using them directly: a typedef will solve this problem.

> Actually, my concern is more about persistent systems. :) In order
> to build a persistent system, the less information resides inside
> the kernel, the better.  On Mach, the ports mechanism is a problem
> since it is entirely managed by the kernel. Beside portability, this
> is a second good reason to not use ports directly. ;)

We will use ports on Mach.  There is no other way to do IPC

reply via email to

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