Why use `thread' as an argument of Syscalls?

Kirk McKusick mckusick at chez.mckusick.com
Mon Jun 5 10:00:42 PDT 2006


> Date: Mon, 5 Jun 2006 11:42:59 -0400 (EDT)
> From: Garrett Wollman <wollman at khavrinen.csail.mit.edu>
> To: rwatson at freebsd.org
> Cc: arch at 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


More information about the freebsd-arch mailing list