Jacob Gorm Hansen jg@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 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 sure.

[ 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.)

Michael