From owner-freebsd-arch Thu Nov 1 15:30:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.250.130.228]) by hub.freebsd.org (Postfix) with ESMTP id A488037B406; Thu, 1 Nov 2001 15:30:34 -0800 (PST) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.3) with ESMTP id fA1NTkI40804; Thu, 1 Nov 2001 15:29:47 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 1 Nov 2001 15:29:46 -0800 (PST) From: Kelly Yancey To: Garance A Drosihn Cc: Julian Elischer , Robert Watson , arch@FreeBSD.ORG Subject: Re: Changes to suser() and friends In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 1 Nov 2001, Garance A Drosihn wrote: > Hmm. It is nicer when fewer source files are mucking around in the > internals of a data structure. Still, it would be nice to collapse > to fewer routines. Would the following be any better? > > int suser __P((struct ucred *cred, struct proc *proc, int flag)); > int suser_td __P((struct ucred *cred, struct thread *thread, int flag)); > > and say that the current 'suser(struct proc *)' > be done as new 'suser(NULL, struct proc *, 0)', > and the current 'suser_td(struct thread *)' > be done as new 'suser_td(NULL, struct thread *, 0)' > or is that too stupid for words? Or maybe switch the positions of > 'cred' and 'proc/thread', just so the most common callers would just > have 'NULL, 0' as the last two parameters. Does that add too much > overhead? > I acknowledge I have no specific insight into suser(), but I would like to add that if you are going to have two different behaviours keyed off of whether a parameter is NULL or not, it is more logical to have two separate functions representing those behaviours. See realloc as an example of what happens when you overload a function with multiple behaviours keyed off of a parameter value. This is presumably the exact sort of overloading that the current (albeit poorly named) set of functions was intended to avoid. Kelly P.S. I like my bikesheds blue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message