Lack of C&C redirection?

Michael Hohmuth hohmuth at
Thu Oct 24 13:52:26 CEST 2002

Jacob Gorm Hansen <jg at> 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
   does not.

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
> features:
> 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, hohmuth at

More information about the l4-hackers mailing list