On Wed, 27 Mar 2002, Robert Watson wrote:
> On Wed, 27 Mar 2002, Bruce Evans wrote:
>
> > On Tue, 26 Mar 2002, John Baldwin wrote:
> >
> > > The patch at the URL below changes the suser() API as follows. Currently we
> > > have four suser() functions that take the following args:
> > >
> > > suser(proc)
> > > suser_td(thread)
> > > suser_xxx(cred, proc, flag)
> > > suser_xxx_td(cred, thread, flag)
> > >
> > > In the new scheme (which has been approved by Robert Watson and is really
> > > his design) we go back to only two functions like so:
> > >
> > > suser(thread, flag)
> > > suser_cred(cred, flag)
> >
> > The former should be suser(thread). In the patch, the flag is nonzero
> > in less than 10% of the calls.
>
> This nice thing about the suser(thread) model, pointed out I think by
> Julian a few months ago, is that it hides the structure contents of thread
> and proc from the caller. suser_cred() requires that the caller not only
> include proc.h, but also that it dereference proc.h, meaning that if
> struct thread or struct proc changes, binary compatibility is broken for
> any precompiled code. Originally, my preference was to always expose the
> credential selection decision in the calling code, but in light of this
> argument, I fell back to using suser() in all places a specific credential
> decision wasn't made. This also had the advantage of hiding whether
> suser(thread) was extracting the credential from the thread or the process
> structure, during the migration. Other than the fact that the flag is
> frequently 0, is there another rationale you have in mind for this? The
> API is still changing (from proc to thread) regardless, so there's no
> compatibility throw-away.
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message