Date: Wed, 27 Mar 2002 14:11:34 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, smp@FreeBSD.ORG Subject: Re: suser() API change patch Message-ID: <Pine.NEB.3.96L.1020327133522.1932Y-100000@fledge.watson.org> In-Reply-To: <20020327213629.S3808-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020327133522.1932Y-100000>