Date: Sat, 27 Nov 1999 19:11:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: David Greenman <dg@root.com>, Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG Subject: Re: Which is the truth? (sycalls and traps) Message-ID: <199911280311.TAA40521@apollo.backplane.com> References: <199911252215.OAA14800@implode.root.com> <199911280257.SAA40292@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oops, let me add an addendum, I didn't answer the original question!
:(Julian wrote...)
:
:Am I also right in assuming that all the registers that the user was
:running when they did the KERNCALL have been saved on the KERNEL stack by
:the time that the above routines are called?
:
:(It's a pitty because if they were saved on the USER stack before teh
:kernel switched to the kernel stack it would have a great simplifying
:effect on kernel threads support :-) (I know that could lead to traps
:during saving the context but..)
No, the userland code runs the system call as if it were almost a normal
subroutine call.
Embedded kernels I have written make use of a couple of tricks, but two
primary ones: (A) A system call is like a subroutine call so you don't
have to save/restore scratch-on-call registers, and (B) When making a
subroutine call from the syscall or interrupt entry code, the procedure
being called will save/restore certain registers so you don't have to.
So the system call does not theoretically have to save every register
and in fact can often get away with saving a minimal set of registers.
But! Our current kernel implementation generates a 'common' trap
frame for all sorts of things and certain calls modify the return
registers, so messing with it would be problematic.
Julian, you shouldn't worry about userland<->kernel context switch so much.
The overhead for going into the kernel and coming out again, if all the
cruft is removed, is *very* tiny -- it's almost like a subroutine call.
We can optimize out the cruft over time.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911280311.TAA40521>