From owner-freebsd-smp Fri Mar 29 19:53:49 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 7DA7F37B416; Fri, 29 Mar 2002 19:53:43 -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 g2U3rZw74135; Fri, 29 Mar 2002 22:53:36 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 29 Mar 2002 22:53:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: John Baldwin , smp@FreeBSD.org, Bruce Evans Subject: Re: suser() API change patch In-Reply-To: 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 Fri, 29 Mar 2002, Julian Elischer wrote: > > > I'll be the first to admit that. It actually suggests the API should be: > > > > > > int suser(void); /* implicitly curthread */ > > > int suser_flags(int flags); /* implicitly curthread */ > > > int suser_cred(struct ucred *cred, int flags); > > > > Well, is this what everyone wants then? I can change it if this is what > > everyone agrees to. In a similar vein, should I get rid of the first argument > > for all the p_canfoo() functions when I change that API as well? > > I think that Bruce is right.. td->td_ucred is only defined for td == > curthread. By removing the argument we stop it being misused.. unless > of course you add a KASSERT() instead.. > > Which is better? To get curthread in the function or to pass it in as an > argument? Peter said that the former is quite a bit slower, but I have > no information on that. There is nothing to stop people using > suser_cred() to do the wrong thing.. > > e.g. suser_cred(other_thread->td_ucred, ....) > > I like that interface if it can be shown to be efficient.. How about we follow the path of least resistance. Move to: int suser(td); int suser_cred(cred, flags); with KASSERT()'s, and then hold a more sustained discussion of whether using curthread is a good idea or not. That way John can get his proc locking stuff in faster. Changing the API later in the manner described (curthread rather than explicit argument) is trivial enough, and not worth holding up the rest, especially given the semantics are likely to be effectively identical (other than use of stack vs. per-thread). suser_cred() is required because there are often a number of relevant credentials in a situation. I've counted up to three in some situations, if not more: p->p_ucred td->td_ucred cached {file->f_cred, socket->so_cred, ...} 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