From owner-freebsd-arch Thu Nov 15 10:54:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 560BB37B405; Thu, 15 Nov 2001 10:54:50 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fAFIsPi02832; Thu, 15 Nov 2001 13:54:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 15 Nov 2001 13:54:25 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dag-Erling Smorgrav Cc: Matthew Dillon , Alfred Perlstein , Greg Lehey , Bruce Evans , Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. In-Reply-To: Message-ID: 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 On 15 Nov 2001, Dag-Erling Smorgrav wrote: > 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. The implicit question behind that, though, is: are there places in the kernel that will always be locked into using curproc/curthread, simply due to the structure and behavior of the kernel environment. For example, I would generally think that 'borrowing' a proc or thread structure is a bad idea, rather, you want that proc or thread to 'loan' you references to supporting ref-counted structures (vmspaces, creds, ...). On a small scale, routines like 'copyin' and 'copyout' already follow the "must use curproc/curthread, so don't bother taking one on the command line" strategy. If we were to assert that a certain class of functions always acted on behalf of the calling thread or process, that's not necessarily bad. It might allow us to substantially simplify locking and reference handling, for example. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message