Date: 15 Nov 2001 15:14:41 +0100
From: Dag-Erling Smorgrav <des@ofug.org>
To: Robert Watson <rwatson@FreeBSD.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: <xzpn11o6rzi.fsf@flood.ping.uio.no>
In-Reply-To: <Pine.NEB.3.96L.1011115090027.87678A-100000@fledge.watson.org>
References: <Pine.NEB.3.96L.1011115090027.87678A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpn11o6rzi.fsf>