From owner-freebsd-smp Wed Mar 27 11:12: 1 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 729ED37B404; Wed, 27 Mar 2002 11:11:53 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2RJBYw38484; Wed, 27 Mar 2002 14:11:35 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 27 Mar 2002 14:11:34 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bruce Evans Cc: John Baldwin , smp@FreeBSD.ORG Subject: Re: suser() API change patch In-Reply-To: <20020327213629.S3808-100000@gamplex.bde.org> Message-ID: 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, 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message