From owner-freebsd-smp Thu Mar 28 2:42: 3 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9132337B404; Thu, 28 Mar 2002 02:41:57 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA31525; Thu, 28 Mar 2002 21:41:55 +1100 Date: Thu, 28 Mar 2002 21:42:30 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson Cc: John Baldwin , Subject: Re: suser() API change patch In-Reply-To: Message-ID: <20020328211326.P7433-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 27 Mar 2002, Robert Watson wrote: > On Wed, 27 Mar 2002, Bruce Evans wrote: > > > On Tue, 26 Mar 2002, John Baldwin wrote: > > > > > The patch at the URL below changes the suser() API as follows. Currently we > > > have four suser() functions that take the following args: > > > > > > suser(proc) > > > suser_td(thread) > > > suser_xxx(cred, proc, flag) > > > suser_xxx_td(cred, thread, flag) > > > > > > In the new scheme (which has been approved by Robert Watson and is really > > > his design) we go back to only two functions like so: > > > > > > suser(thread, flag) > > > suser_cred(cred, flag) > > > > The former should be suser(thread). In the patch, the flag is nonzero > > in less than 10% of the calls. > > This nice thing about the suser(thread) model, pointed out I think by > Julian a few months ago, is that it hides the structure contents of thread > and proc from the caller. suser_cred() requires that the caller not only > include proc.h, but also that it dereference proc.h, meaning that if > struct thread or struct proc changes, binary compatibility is broken for > any precompiled code. Originally, my preference was to always expose the > credential selection decision in the calling code, but in light of this > argument, I fell back to using suser() in all places a specific credential > decision wasn't made. This also had the advantage of hiding whether > suser(thread) was extracting the credential from the thread or the process > structure, during the migration. Other than the fact that the flag is > frequently 0, is there another rationale you have in mind for this? The > API is still changing (from proc to thread) regardless, so there's no > compatibility throw-away. suser(thread, flag) could still exist (named somthing like suser_flag()) if it is used enough to justify it. My main point is that the flag is rarely used, so the interface shouldn't be bloated to pass it. Another point: td->td_ucred can only be safely used without locking if td is curthread. Our current code mostly assumes this. suser(td) can easily check that td is curthread, but this is a silly reason to use a bloated interface. It is just bug for bug compatible with passing thread pointers around a lot. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message