Thanks Adam, I must be missing something.
Regardless of the mechanism used, an IPC must be sent from the l4 u-kernel to the linux server, so the linux server can deal with the "fake intterupt" (a system call). I am using V2, so, according to previous discussion, the interrupt parameters and other data are pushed into a data structure that the l4 thread (eg the linux server) can get them after receiving the notification IPC (eg with COOKIE_1, COOKIE_2). There must be an IPC regardless of the mechnanism, is this correct? Furthermore, where is this sent in l4 and where is it handled in l4linux ?
Thanks, Andrew Davenport
Quoting Adam Lackorzynski adam@os.inf.tu-dresden.de:
On Mon Jun 13, 2005 at 15:03:35 -0400, Andrew Davenport wrote:
i see thread::raise_exception(ts), and i know this is where l4 notices a
linux
sys call (int 0x80), however, i do *not* see where the ipc is sent to the linux server to tell it that a syscall has occured (and to get the
parameters
and handle it)...
As already mentioned, there are two ways an exception gets signalled to user land. One is the exception IPC mechanism, the other is the "IDT" mechanism.
Both mechanisms start in Thread::handle_slow_trap().
Thread::raise_exception() is used for the idt mechanism. For this to work, a thread needs to register exception handlers (basically function pointers in a table for each exception) that are called if an exception is raised. So if the thread executes an 'int $0x80' it traps into the kernel and when resuming to user land continues its execution at the code defined for exception 13 (int 80 will trigger an exception 13). All thread state is preserved. No IPC is involved.
The other mechanism, exception IPC, basically works like a page fault. When an exception happens, the kernel generates an exception to the exception handler along with the state and waits for a response to set some new state for the thread which then continues. In handle_slow_trap this is initiated in the Thread::snd_exception() function, and goes on with Thread::exception() where the IPC is sent and the response received.
Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers