All local system calls are asynchronous (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 11 Nov 2010 02:32:44 +0000 (18:32 -0800)
committerKevin Klues <klueska@cs.berkeley.edu>
Thu, 3 Nov 2011 00:35:56 +0000 (17:35 -0700)
commita189e444f695d121006448346174ed374fe4ee34
treee45f0b6b6b95c7eb8140bc411b5fe50c08fc4c73
parentb4528e644505a6b9e782ad7d6d88d327907906f9
All local system calls are asynchronous (XCC)

Rebuild your cross compiler.

For now, userspace just submits a call and then spins on the response
(synchronous in userspace, but async in the kernel).  When the kernel
blocks, it first attempts to start/run more syscalls, then restarts the
current_tf (which gets the process back to where it trapped into the
kernel).  The kernel will return how many syscalls it started, (similar
to Xen's interface), so if you batch calls, you need to make sure they
all started.

Regardless of whether the call blocked or not, the kernel will return
via smp_idle().  A blocked call will simply post its results and
smp_idle(), just like when it didn't block.  Current_tf only has meaning
the "first time", when the process first trapped in.  After a kthread
unblocks, current_tf has already restarted, so it no longer has meaning
(and should be 0'd).  Things get a bit tricky with some syscalls that
don't return (like yield, resource_req, exec, etc).  Fork is also a bit
tricky.

I can see why people like synchronous calls backed by a single kernel
task - but this is quite awesome when it works right.
14 files changed:
kern/arch/i686/ros/bits/syscall.h
kern/arch/i686/ros/syscall.h
kern/arch/i686/trap.c
kern/arch/sparc/ros/syscall.h
kern/arch/sparc/trap.c
kern/include/ros/ring_syscall.h
kern/include/ros/syscall.h
kern/include/smp.h
kern/include/syscall.h
kern/src/arsc.c
kern/src/resource.c
kern/src/smp.c
kern/src/syscall.c
tools/compilers/gcc-glibc/glibc-2.11.1-ros/sysdeps/ros/i386/tls.h