On Thu Aug 24, 2006 at 17:01:54 +0200, Oskar Senft wrote:
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.
It is being prepared to run Linux code, which is usually for doing interrupt like work.
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.
So, Z is called a kernel thread then.
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 ...
It's not the 'simple IPC call' that requires this but your requirements. Additionally, a kernel thread (one which is created with kernel_thread() or friends) isn't an L4 thread but an Linux kernel-internal process. This reduces the needed threads to two. One to receive asynchronous events (similar to interrupts) which schedules work to be done and another worker thread in the server to receive completion events. Depending on what the main thread in your server is doing it even could receive the completion events itself.
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.
You could make it the other way around and do an open-wait on the server side. But I don't know if your server architecture allows this.
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.
A Linux user process can do this just fine. L4sleeping and calling Linux functionality.
The Linux kernel main thread cannot do L4 sleeping, at least not if it's supposed to do other things as well, like running some user programs or keeping network connections alive. Getting more 'main threads' into the play is possible but requires some good amount of work which hasn't been done up to now.
Adam