From owner-freebsd-arch Sun Nov 11 17:50:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id B122F37B416; Sun, 11 Nov 2001 17:50:53 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id fABIFG336949; Sun, 11 Nov 2001 10:15:21 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200111111815.fABIFG336949@beastie.mckusick.com> To: Robert Watson Subject: Re: cur{thread/proc}, or not. Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: Your message of "Sun, 11 Nov 2001 10:31:54 EST." Date: Sun, 11 Nov 2001 10:15:16 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Some many years ago, I tried to get rid of all the references to curproc in the filesystem code, and quickly came to the realization that it would require adding a proc pointer to virtually every subroutine in the filesystem code. For the reasons that you have noted, this is ugly and adds bloat to the stack space. On the other hand, there are places where the filesystem code does not want to use the current process credential. One of the more evident ones is in the NFS server code which wants to pass down the credential of the requesting client rather than its own. Solaris uses a very ugly hack where the server thread replaces its credential with that of its client, does the VOP call, then puts its own credential back when it returns. This sort of problem could exist in almost any instance where the kernel is acting as a server. So, completely removing process/credential references from the kernel interfaces is not the right solution either. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message