From owner-freebsd-smp Fri Mar 29 12:40:15 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id B3BB037B416; Fri, 29 Mar 2002 12:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020329204008.WFFB1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 29 Mar 2002 20:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA00825; Fri, 29 Mar 2002 12:29:00 -0800 (PST) Date: Fri, 29 Mar 2002 12:28:59 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Robert Watson , 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, John Baldwin wrote: > > On 29-Mar-2002 Robert Watson wrote: > > > > On Thu, 28 Mar 2002, Julian Elischer wrote: > > > >> On Thu, 28 Mar 2002, Bruce Evans wrote: > >> > 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 does have a point.. > > > > 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.. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message