Date: Mon, 5 Jun 2006 16:56:06 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Suleiman Souhlal <ssouhlal@FreeBSD.org> Cc: Daniel Eischen <deischen@freebsd.org>, MingyanGuo <guomingyan@gmail.com>, delphij@gmail.com, freebsd-arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? Message-ID: <20060605165355.L50057@fledge.watson.org> In-Reply-To: <448450FD.4030709@FreeBSD.org> References: <1fa17f810606050044k2847e4a2i150eb934ed84006f@mail.gmail.com> <Pine.GSO.4.64.0606050744190.13542@sea.ntplx.net> <1fa17f810606050608l5bd2ec5ch37663375f6fa5b64@mail.gmail.com> <Pine.GSO.4.64.0606051118180.14745@sea.ntplx.net> <20060605163559.N50057@fledge.watson.org> <448450FD.4030709@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jun 2006, Suleiman Souhlal wrote: > Robert Watson wrote: >> >> On Mon, 5 Jun 2006, Daniel Eischen wrote: >> >>>> They are the same questions, I think ;-). Now would you please explain >>>> "why use `proc' as an argument of Syscalls" to me :)? I've read some >>>> source code of the kernel, but no comments about it found. >>> >>> I don't know. Convention? It makes sense to me. >> >> Certainly consistency. Most system calls do actually use the argument at >> some point -- be it to look up a file descriptor, access control, or the >> like, and the calling context has it for free and in-hand anyway. > > But couldn't they just use curthread/curproc? In the past, in micro-benchmarking, I've measured a small performance hit from using per-cpu variables over variables already in the stack. However, that was quite a while ago, and I'm not entirely convinced the test results were valid. In the general case, it's pretty helpful to be able to pass in, for example, explicit credential references, as it means you can do acess control checks, auditing, accounting, etc, against arbitrary credentials rather than always against curthread->td_ucred. In a number of places, we pass threads down the stack where we mean to pass credentials, such as at several spots in the network stack. There are also places where the process is passed around so it can become a later argument to lockmgr() locking primitives, and since those are decreasingly used, the references are increasingly unnecessary. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060605165355.L50057>