Hello,
Thanks for all the previous help. I was wondering: Suppose I have a filenumber as a syscall param (from linux server) inside Thread::do_send() in l4. I want the inode number for that filenumber, how would I get that? Also, how would I get a block list from an inode number?
Thanks, andrew
Quoting Adam Lackorzynski adam@os.inf.tu-dresden.de:
On Tue Jun 14, 2005 at 13:20:25 -0400, Andrew Davenport wrote:
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 ?
Yes, eventually an IPC is sent in both cases. But in the idt case this IPC to the linux server is generated by user land, the kernel itself has nothing to do with generating the IPC. I thought we were talking about kernel internals.
Ok, let's concentrate on one case, l4linux 2.6, exc. IPC.
Linux program executes:
mov $20, %eax int $0x80
An exception is generated and execution is continued in the kernel at vec0d_gen_prot in entry-ia32-ux.S. There we push some things on the stack and call the trap_handler. The handler is thread-ia32-ux.cpp:thread_handle_trap() which calls thread::handle_slow_trap(). handle_slow_trap() in the same file now goes through the possible things that can happen (instruction emulation etc) and eventually comes to the
// send exception IPC if requested if (snd_exception(ts)) goto success;
lines. This path is taken in our case.
When the exception handler (same as the pager) of the faulting thread accepts exception IPC we go on in Thread::exception(). Thread::exception() is the function where the send and receive IPCs to the exception handler are set up. Also noteworthy, the utcb_handler for the faulting thread is modified to copy the trap state instead of the utcb itself. Finally, we come to do_send() where the IPC is sent to the handler. The faulting thread now sleeps waiting for do_send() to come back. When the Linux server has received the message it goes on to do_receive() waiting for a reply from the Linux server.
So, now the Linux server wakes up and receives the exception IPC. It also finds the trap state of the faulting thread in its utcb. By looking at the trap number (==13) and the error code (==0x402) it figures out that the Linux program wanted to execute an 'int80'. By looking at eax it knows that sys_getpid is requested which is then called via the syscall-table. Coming back from the syscall, the return value is stored in the eax field of the utcb and the instruction pointer in the utcb is increased by 2 to point after the 'int80'. Then the exception reply IPC is sent. The Linux server now waits for the next request. All this code is in the dispatch.c file in the L4Linux tree.
Now the kernel wakes up again from its do_receive(). The contents of the utcb are copied to the trap state structure of the faulting thread. The utcb handler is reset. That's it in Thread::exception(). We now come back to handle_slow_trap() where we jump to 'success' because we have handled the exception. We come back to the entry.S code where we clear up the stack and finally 'iret' out to userland again.
The Linux user program now continues its execution after the 'int80', and eax is now whatever the PID of the Linux program is.
I hope this makes it more clear what happens when a Linux program executes an int 80.
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