Date: Mon, 05 Jun 2006 10:00:24 -0700 From: Kirk McKusick <mckusick@chez.mckusick.com> To: Garrett Wollman <wollman@khavrinen.csail.mit.edu> Cc: arch@freebsd.org, rwatson@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? Message-ID: <200606051700.k55H0OeJ092393@chez.mckusick.com> In-Reply-To: Your message of "Mon, 05 Jun 2006 11:42:59 EDT."
next in thread | raw e-mail | index | archive | help
> Date: Mon, 5 Jun 2006 11:42:59 -0400 (EDT) > From: Garrett Wollman <wollman@khavrinen.csail.mit.edu> > To: rwatson@freebsd.org > Cc: arch@freebsd.org > Subject: Re: Why use `thread' as an argument of Syscalls? > > Robert Watson writes: > > >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. > > I believe it was the intention of the 4.4BSD developers to completely > eliminate "curproc" (as they had already successfully eliminated "u"), > on the theory that with a modern (RISC) processor architecture, > passing the current process as a parameter wouldn't cost anything > (since it would stay in a register for the life of the system call) > whereas making a context-switched "curproc" would be expensive. > > -GAWollman Your above analysis is correct. When we made the pass over the code base to eliminate all references to "u." we had also hoped to get rid of all references to "curproc". While we were successful with the former, it eventually became clear that the latter was not practical. But by that time, the convention of passing the current process pointer to Syscall was established, and removing it did not seem to be worth the effort. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606051700.k55H0OeJ092393>