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 <jhb@FreeBSD.org> <>< 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