Date: Fri, 29 Mar 2002 22:53:35 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.org>, smp@FreeBSD.org, Bruce Evans <bde@zeta.org.au> Subject: Re: suser() API change patch Message-ID: <Pine.NEB.3.96L.1020329225016.73912E-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0203291219230.726-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020329225016.73912E-100000>