Date: Fri, 29 Mar 2002 16:38:12 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Kirk McKusick <mckusick@beastie.mckusick.com> Cc: arch@FreeBSD.ORG Subject: Re: curthread vs. passing thread pointers around Message-ID: <XFMail.20020329163812.jhb@FreeBSD.org> In-Reply-To: <200203292130.g2TLUrD01863@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29-Mar-2002 Kirk McKusick wrote: > Date: Fri, 29 Mar 2002 14:32:22 -0500 (EST) > From: John Baldwin <jhb@FreeBSD.ORG> > To: arch@FreeBSD.ORG > Subject: curthread vs. passing thread pointers around > Sender: owner-freebsd-arch@FreeBSD.ORG > List-ID: <freebsd-arch.FreeBSD.ORG> > List-Archive: <http://docs.freebsd.org/mail/>; (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 <jhb@FreeBSD.org> <>< 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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020329163812.jhb>