[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.
Michael
--
address@hidden, address@hidden
http://home.pages.de/~hohmuth/
- Re: Moving forward (was L4Hurd at Sourceforge), (continued)
- vk_l4 -- CVS Setup, Ian Duggan, 2001/10/23
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/23
- Re: vk_l4 -- CVS Setup, Jeroen Dekkers, 2001/10/24
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/24
- Re: vk_l4 -- CVS Setup, Niels Möller, 2001/10/25
- Re: vk_l4 -- CVS Setup, Ian Duggan, 2001/10/25
- Re: vk_l4 -- CVS Setup, Debian UserAd Buijsen, 2001/10/26
- Network-transparent IPC (was Re: vk_l4 -- CVS Setup),
Michael Hohmuth <=
- Re: Network-transparent IPC (was Re: vk_l4 -- CVS Setup), Farid Hajji, 2001/10/30
- Re: Network-transparent IPC (was Re: vk_l4 -- CVS Setup), Michael Hohmuth, 2001/10/30
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Niels Möller, 2001/10/30
- Re: vk_l4 -- CVS Setup, Espen Skoglund, 2001/10/30
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Neal H Walfield, 2001/10/25
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Neal H Walfield, 2001/10/30