From owner-freebsd-arch Fri Mar 29 13:38:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 36B0137B400 for ; Fri, 29 Mar 2002 13:38:11 -0800 (PST) Received: (qmail 15683 invoked from network); 29 Mar 2002 21:38:10 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2002 21:38:10 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2TLcwv01732; Fri, 29 Mar 2002 16:38:58 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203292130.g2TLUrD01863@beastie.mckusick.com> Date: Fri, 29 Mar 2002 16:38:12 -0500 (EST) From: John Baldwin To: Kirk McKusick Subject: Re: curthread vs. passing thread pointers around Cc: arch@FreeBSD.ORG 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 On 29-Mar-2002 Kirk McKusick wrote: > Date: Fri, 29 Mar 2002 14:32:22 -0500 (EST) > From: John Baldwin > To: arch@FreeBSD.ORG > Subject: curthread vs. passing thread pointers around > Sender: owner-freebsd-arch@FreeBSD.ORG > List-ID: > List-Archive: (Web Archive) > > During a discussion on the smp@ list about changes to the suser() > API to make use of td_ucred, it was brought up that the new suser() > would be assuming that the passed in thread pointer was curthread > so why not just use curthread in suser() and not pass in a pointer > at all. There are several places in the kernel where the same > assumption is made. Thus, my question is: which general approach > should we follow, and should we perhaps switch to using explicit > curthread's everywhere and stop passing thread pointers around on > the stack? > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > The whole business of passing proc pointers got started in the late > 1980's when we went on a big kernel cleanup campaign to get rid of > all references to u.u_variable. Most of that efforts worked out > well. For example, having most kernel functions return an error > rather than stuffing it in u.u_error. That also explains the > numerous /* XXX */ comments scattered through the kernel whenever > curproc (or now curthread) gets used; the idea was that the proc > (or thread) pointer should have been a parameter. A few years ago > I set out to try to clean up all those global references, and found > that I had to add a proc pointer parameter to nearly every function > in the top half of the kernel. I concluded that the extra overhead > was simply not worth it, and that we should just continue using the > global pointer as we do now. There are still instances where > credentials should be passed as parameters since it is not the case > that using the current threads credential is the right thing to do. > For example, the NFS server wants to use the credential of the > incoming request, not its own in deciding filesystem access. I > can also believe that suser() might have places where it would > want to use a different credential than that of the current thread. > So, while removing proc/thread parameters from existing functions > is reasonable, we should consider whether they should be replaced > with pointers to credentials. Yes, in the suser() discussion on smp@ we will have at least two versions of suser(), one which uses the credential of curthread, and another which accepts a credential directly to perform the test against. > Kirk McKusick -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message