From owner-freebsd-arch Mon Nov 12 15:20:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 7FEE937B416; Mon, 12 Nov 2001 15:20:11 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA95318; Mon, 12 Nov 2001 15:02:12 -0800 (PST) Date: Mon, 12 Nov 2001 15:02:11 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: Robert Watson , freebsd-arch@FreeBSD.org Subject: Re: cur{thread/proc}, or not. In-Reply-To: <3BF05241.74F895EF@mindspring.com> 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 Mon, 12 Nov 2001, Terry Lambert wrote: > > I think this is the wrong direction, but if you wanted to do this, > I think that you would need to put the cur* symbols into the per > CPU private pages. This is problematic in the extreme, because it > means that you must set these values each time going down, in order > to be able to substitute a per CPU global for the stack reference. curproc and curthread ARE in the per-cpu private pages. on x86, the %fs segment register points to a small segment that includes the appropriate pages for that cpu. Each cpu is initialised with a different %fs register value. Your private info is accessed as an offset into the 'f' segment which is not used by anything else. 'curthread' is a macro that generates %fs(gd_curthread) (I forget the exact syntax) Similar for other CPUs > I think this is a bad thing, in general, and will lead only to > trouble later. > > I would much rather that the credentials be object referenced off > of non-process, non-thread objects, based on whatever the correct > scoping really is, for the security model you want to enforce. My > "accept" example is only one of a class of changes that could > facilitate this. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message