Hi L4Linux hackers!
When creating threads within the L4Linux kernel and running the command l4x_prepare_irq_thread(current_thread_info());
the thread obviously ;-) is being run in the interrupt context. This means the thread (let's call it thread X) must not sleep and is restricted in other ways. This implies, that I cannot run Linux functions that would cause the thread X to sleep - that's clear.
On top of that, let's create the following scenario: some other task issues an IPC call to the described L4Linux thread X waiting for IPC. For handling the call, thread X would need to use Linux functions causing thread X to sleep. This will cause a kernel panic, deadlock or other severe errors.
Our idea for solving that is to use *another* "normal" *Linux* thread (let's call it Z) not running in interrupt context. This thread Z would sleep until it is awakened by the L4Linux thread X and then call the Linux function that causes thread Z to sleep. But: the L4Linux thread X would have to send a reply to the IPC call immediately. So, I would need another L4 thread Y (not known to L4Linux), acting as a notifier thread for the calling task. This thread would receive the IPC notify call, go into a L4 semaphore waiting to be woken by thread Z.
So, the simple IPC call from another task which should use a Linux function requires *three* threads to run ...
If we had the possiblity to send the reply to an incoming IPC from _another_ thread than the called thread, this at least would eliminate the notifier thread Y.
If we had the possibility to run L4Linux threads (like thread X) in some Linux context where it could sleep, this could even eliminate both threads Y and Z.
Is there a simpler solution? Is it possible to make it easier?
Best regards Oskar.