nathan's description is very good; the one additional thing I'd add is
that the trap frame is present on the kernel stack, not the user
stack; switching between user and kernel mode involves switching
stacks.

The kernel stack for a process lives in a different part of memory
from the user stack -- it's in the kernel's virtual address space, not
the user's.

when a process is running in user mode, there's nothing to speak of on
the kernel stack; the kernel always "returns" into user space.  In the
case of both exec() and signal(), it "returns" using a faked-up trap
frame.

machine-dependant code is responsible for telling the hardware and/or
locore where to find a processes kernel stack pointer when trapping
from user code.

so, the syscall path looks like:

	user syscall stub invokes the machine-dependant "system call"
	instruction.

	hardware starts running in kernel mode
	hardware or locore switches to kernel stack 
	locore syscall trap handler starts running
	locore creates/finishes trap frame 
	locore handler invokes system call handler
	locore restores user context from trap frame
	locore switches back to user mode and user stack.
		(typically with "return from interrupt" instruction)

	user syscall stub returns into user code possbly via cerror

If the process is signalled while in the kernel, the kernel signal
code inserts a new frame on to the *user* stack, and whacks the
trapframe on the kernel stack so that when the process returns to user
mode, it ends up running the signal trampoline code (which invokes the
handler) rather than the system call stub.
						- Bill