Lack of C&C redirection?
hohmuth at sax.de
Thu Oct 24 13:52:26 CEST 2002
Jacob Gorm Hansen <jg at ioi.dk> writes:
> the Fiasco website says that nobody ever implemented C&C redirection for
> L4. Is this planned?
No, currently it is not planned for any L4 version that does not
already have it (i.e., L4/MIPS). However, a simple experimental
redirection feature is in the pipe for Fiasco (awaits commitment to
main branch of source tree) -- see below.
> What will happen in the current version, if I try to ipc to a task
> outside my clan?
This depends on the L4 implementation you use.
1. With L4/x86 version 2 (aka. Lemon Pip), for example, has a broken
implementation of C&C: Message diversion works, but deceiving IPC
2. Fiasco currently just ignores C&C for IPC and implements neither
message diversion nor deceiving IPC; it just directly sends
out-of-clan messages to the target thread.
3. I believe that both L4/x86 version X (aka. Lime Pip) and Hazelnut
implement some form of message diversion and deceiving IPC, using a
variant of the redirector concept I explain below, but I am not
[ from another message ]
> OK. What I am trying to do is detect if a l4linux process has changed
> its task number, which it sometimes does in my setup.
> What we have is a modified version of l4linux, with the following
> 1) Multiple instances run atop a HAL made with OSKit.
> 2) L4linuxes may suspend and migrate to other physical host.
> This work fine, but only as long as I stick to the same task numbers
> across migrations. I need to be able to detect if a task is trying to
> perform out-of-clan ipc, so that either it's chief or the task itself
> (upon receival of an error code from the ipc call) may take appropriate
> action (recalc the dest id and retry).
> If the stale dest id point to a non-existing task, I get error 0x10,
> which is fine, but what happens (in Fiasco) if the task exists, just in
> some other clan?
The message is sent to the existing task.
I believe that your problem can be solved with the experimental Fiasco
feature I mentioned:
Sebastian Lehmann has implemented a redirection concept for Fiasco
which will be merged into the source code soon. He just made
modifications he needed to implement network-transparent IPC. This
concept works as follows:
For each thread T, any other thread S with a higher MCP (i.e.,
schedulers) can define an external redirector thread, R. Whenever T
attempts an inter-address-space IPC, the message is diverted to R. R
can fake any sender ID when sending messages to T, and R can can fake
T's sender ID when sending messages elsewhere. In Sebastian's
concept, T's messages can be diverted to R, but messages sent to T are
not automatically redirected to R.
Using this scheme, you can assign each L4Linux client a redirector
thread inside the L4Linux instance. From the L4Linux-clients' point
of view, the external thread-ID space will be completely virtualized.
(If the task numbers of the L4Linux clients can change as well,
virtualizing the task-internal thread-ID space as well is a different
problem. I haven't thought about it much, but I guess it is a
challenge of its own with Fiasco's L4-version-2 API, whereas L4
version X.2 will make it trivial.)
hohmuth at sax.de, hohmuth at inf.tu-dresden.de
More information about the l4-hackers