From owner-freebsd-smp Sat Mar 30 0:37:53 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2880637B41A; Sat, 30 Mar 2002 00:37:49 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA24056; Sat, 30 Mar 2002 19:37:46 +1100 Date: Sat, 30 Mar 2002 19:38:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson Cc: Julian Elischer , John Baldwin , Subject: Re: suser() API change patch In-Reply-To: Message-ID: <20020330192622.X630-100000@gamplex.bde.org> 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, 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 majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message