Date: Thu, 15 Nov 2001 13:54:25 -0500 (EST)
From: Robert Watson <rwatson@FreeBSD.ORG>
To: Dag-Erling Smorgrav <des@ofug.org>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alfred Perlstein <bright@mu.org>, Greg Lehey <grog@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Peter Wemm <peter@wemm.org>, freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
Message-ID: <Pine.NEB.3.96L.1011115135118.1877C-100000@fledge.watson.org>
In-Reply-To: <xzpn11o6rzi.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Nov 2001, Dag-Erling Smorgrav wrote: > Robert Watson <rwatson@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011115135118.1877C-100000>