Hi!
From: "Adam Lackorzynski" adam@os.inf.tu-dresden.de
On Mon Sep 23, 2002 at 01:06:56 +0000, Alexey Mandrookin wrote:
I found strange behaviour of l4_i386_ipc_wait(). In case of interrupt IPC, it return wrong value of the thread id of IPC source.
You're waiting for a specific interrupt, how useful it is to know the "source" if you already have the dest id (this specific interrupt)?
Due to synchronous style of micro kernel, it is very useful to know IPC source.
Point is that thread wait events from two sources and it need exactly distinguish
who is sent event.
Let me explain problem. Thread 5.1 is an interrupt handler. Thread 5.0 is a user task.
By the term, user task cannot wait for key press events, it need only occasionally,
when no calculations or other work present. The way of hardware interrupt is:
OS interrupt -> Interrupt handler (5.1) -> User task (5.0)
As you can see, the Task 5.0 must wait for IPC from thread 5.1, otherwise task 5.1
will locked in l4_i386_ipc_send () function. In that case, next interrupt can be lost or pended.
Idea is send signal from 5.0 to 5.1, which will inform interrupt thread what a user task waits
for data. Next, then hardware interrupt coming, it check what user task ready for receive
(i.e. in IPC wait state). If user task waits, then IPC send from 5.1 to 5.0, otherwise data puts
into buffer.
Of course, thread 5.1 can try to send IPC to thread 5.0 in any case, and if l4_i386_ipc_send()
return L4_IPC_SETIMEOUT status, put event into buffer. In that case possible situation,
when data present at buffer, user task waits for event and no new interrupts coming.
Another example: COM1 and COM2 generate different interrupt. It is better to write single
device driver for both ports. It that case also need to know the interrupt source.
If you're waiting for an interrupt, use ipc receive, don't care about source stuff (also see p. 29 of the L4-V2 ref manual).
Yes, I read in that document, but there some differences with
http://os.inf.tu-dresden.de/papers_ps/fiasco-spec.ps.gz
Anyway, returned values not covers by any L4 documents and look strange.
Best regards
Alexei