Date: Fri, 29 Mar 2002 13:30:52 -0800 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: curthread vs. passing thread pointers around Message-ID: <200203292130.g2TLUrD01863@beastie.mckusick.com> In-Reply-To: Your message of "Fri, 29 Mar 2002 14:32:22 EST." <XFMail.20020329143222.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Kirk McKusick 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?200203292130.g2TLUrD01863>