L4Linux threads - interrupt context

[Adam Lackorzynski]

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
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/