Re: suser() API change patch

On Fri, 29 Mar 2002, Robert Watson wrote:

> 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).

I agree with this.  I wouldn't remove td args without first adding lots
of KASSERTS to show that td is always curthread.

I think initialization and finalization are the main cases where
td != curthread.  boot() perpetrates sync(&thread0) even for non-panic
reboots when there should be no problem using curthread.

Bruce


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-smp" in the body of the message