From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:00:31 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07AA016BF2E; Mon, 5 Jun 2006 17:00:31 +0000 (UTC) (envelope-from mckusick@chez.mckusick.com) Received: from chez.mckusick.com (dsl081-247-049.sfo1.dsl.speakeasy.net [64.81.247.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F2D43D7B; Mon, 5 Jun 2006 17:00:22 +0000 (GMT) (envelope-from mckusick@chez.mckusick.com) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.13.6/8.13.1) with ESMTP id k55H0OeJ092393; Mon, 5 Jun 2006 10:00:24 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <200606051700.k55H0OeJ092393@chez.mckusick.com> To: Garrett Wollman In-Reply-To: Your message of "Mon, 05 Jun 2006 11:42:59 EDT." Date: Mon, 05 Jun 2006 10:00:24 -0700 From: Kirk McKusick Cc: arch@freebsd.org, rwatson@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 17:00:42 -0000 > Date: Mon, 5 Jun 2006 11:42:59 -0400 (EDT) > From: Garrett Wollman > 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