From owner-freebsd-current Sat Nov 27 19:11:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CF4E14D75 for ; Sat, 27 Nov 1999 19:11:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA40521; Sat, 27 Nov 1999 19:11:41 -0800 (PST) (envelope-from dillon) Date: Sat, 27 Nov 1999 19:11:41 -0800 (PST) From: Matthew Dillon Message-Id: <199911280311.TAA40521@apollo.backplane.com> To: Matthew Dillon Cc: David Greenman , Julian Elischer , current@FreeBSD.ORG Subject: Re: Which is the truth? (sycalls and traps) References: <199911252215.OAA14800@implode.root.com> <199911280257.SAA40292@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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