[Top][All Lists]

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

Network-transparent IPC (was Re: vk_l4 -- CVS Setup)

From: Michael Hohmuth
Subject: Network-transparent IPC (was Re: vk_l4 -- CVS Setup)
Date: 29 Oct 2001 12:49:42 +0100
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

address@hidden (Debian UserAd Buijsen) writes:
> [ Ian Duggan <address@hidden> writes: ]

> > Reading the L4 definition, the IPC mechanisms seem very specific to
> > machines with some sort of shared address space access. It think it
> > would be very difficult to extend the idea of network transparency to L4
> > without destroying it's simplicity. L4 is already doing a number of
> > memory tricks to keep context switching cheap between it's threads,
> > using segment registers and such, where possible.
> > 
> > Network transparent RPC definitely seems like a userspace candidate to
> > me. The RPC you are describing would be built as messages to some sort
> > of RPC server (L4 server) making use of the L4 ipc calls to communicate
> > the message to the server. All concepts of networking and such would be
> > strictly outside of the L4 kernel.
> Version 2 of the L4 spec. has Unique IDs containing a "site" field, so
> kernel-assisted remote IPC was considered at a time, I presume.  A
> "site-fault" for non-local IPC would be one method to handle it, or a
> generalized form of IPC redirection.

Correct.  Network-transparent IPC can be implemented completely on
user level in an L4v2 implementation that correctly implements the
clans-and-chiefs model:  IPC to a destination with a non-local site
field would we redirected to a thread's ``chief,'' which could the
decide to send it across the network.  There, the receiver, presumably
another chief, could re-send the IPC, ``faking'' the new message's
return address to look like the original sender on the first machine.

However, developers generally deemed the clans-and-chiefs model too
limiting and uncomfortable, so most L4v2 implementations do not
support it, and L4v4 will sport a new redirection model (which will
also allow network-transparent IPC).

As an aside, network-transparent IPC for L4 would be rather complex to
implement: If it was to support messages containing flexpage mappings
(and not just memory-copying IPC), it would have to provide some sort
of distributed shared memory.

address@hidden, address@hidden

reply via email to

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