From owner-freebsd-hackers Fri Sep 20 05:31:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA20505 for hackers-outgoing; Fri, 20 Sep 1996 05:31:44 -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 FAA20390 for ; Fri, 20 Sep 1996 05:31:32 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.6/CET-v2.1) with SMTP id MAA25502; Fri, 20 Sep 1996 12:28:22 GMT Date: Fri, 20 Sep 1996 21:28:22 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: freebsd-hackers@FreeBSD.org Subject: Re: thread stacks and protections (was Re: attribute/inode caching) In-Reply-To: <199609191856.LAA01219@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 Thu, 19 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, > > > > 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. > > Maybe I don't understand the question, or maybe you aren't asking in > the context of page-anonymity based protections, which are statistical > protections using MMU faulting rather than domain crossing protections > using instruction faulting. Your reference to thread stacks being able to grow is why I brought up the kernel stack being in the u-area. Where would kernel thread stacks go if you wanted them to be able to grow dynamically? > I think John Dyson's response is best: it can be implemented (I wouldn't > say it was as trivial to do as John implies, but then John is a VM > guy and I am an FS guy), but we need to make sure that it's the right > thing being implemented. I think John meant that the kernel stack can easily be moved somewhere else as I was talking about an interim non-smp step. BTW, an interim step doesn't sound necessary after listening to John's description of the flexibility already enabled in the current framework, unless people really wanted more kernel stack then there is now and the tradeoffs were reasonable. Regards, Mike Hancock