From owner-freebsd-arch Thu Nov 15 6:14:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8661537B405; Thu, 15 Nov 2001 06:14:45 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id D3A9614C40; Thu, 15 Nov 2001 15:14:41 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Robert Watson Cc: Matthew Dillon , Alfred Perlstein , Greg Lehey , Bruce Evans , Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. References: From: Dag-Erling Smorgrav Date: 15 Nov 2001 15:14:41 +0100 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson writes: > In my mind, that is in fact the primary argument *to* use curproc instead > of passing around process and thread pointers. If the routine implicitly > assumes curproc or curthread for locking/referencing purposes, either > there needs to be a way to assert that: > [example of PROMISE_ME_ITS_CURTHREAD_OR_DIE_HORRIBLY(td)] > or, we simply need to use curthread and curproc, and not allow anything > else to be passed in. I greatly prefer the first approach, as it allows us to gradually fix parts of the kernel to be curthread-agnostic without the hassle and breakage that inevitably follow from massive API changes. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message