From owner-freebsd-hackers Wed Sep 18 18:33:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA09706 for hackers-outgoing; Wed, 18 Sep 1996 18:33:54 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA09681 for ; Wed, 18 Sep 1996 18:33:50 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id BAA12453; Thu, 19 Sep 1996 01:31:23 GMT Date: Thu, 19 Sep 1996 10:31:23 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: dg@Root.COM, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@FreeBSD.org Subject: thread stacks and protections (was Re: attribute/inode caching) In-Reply-To: <199609171816.LAA04481@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Sep 1996, Terry Lambert wrote: > Personally, I'd like to use page anonymity based protections to establish > Chorus-like access priveledge domains for IPC; specifically, for stacks > capable of being grown by fault for use by threads. I think the POSIX > model is broken: I should not be required to preallocate stack for a > thread just because SVR4 and Solaris have bogus architectures (actually, > the SVR4 VM does *not* impose this limitation: it is a limitation of > the threading code alone. Steve Baumel, the author of the SVR4 VM, and > I discussed this at some length when discussing context sharing models > that would be useful for the NetWare for UNIX product). > How does one implement a u-area concept on top of Chorus? A lot of stuff that used to be in the u-area has been moved out to the proc and other structures in 4.4BSD. Maybe moving the kernel stack out of the u-area and generalizing the proc and u-cred stuff can be a step toward what your talking about. Regards, Mike Hancock