From owner-freebsd-hackers Wed Sep 18 20:13:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA25238 for hackers-outgoing; Wed, 18 Sep 1996 20:13:55 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA25201 for ; Wed, 18 Sep 1996 20:13:49 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id WAA01140; Wed, 18 Sep 1996 22:09:31 -0500 (EST) From: "John S. Dyson" Message-Id: <199609190309.WAA01140@dyson.iquest.net> Subject: Re: thread stacks and protections (was Re: attribute/inode caching) To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 18 Sep 1996 22:09:31 -0500 (EST) Cc: terry@lambert.org, dg@Root.COM, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 19, 96 10:31:23 am Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. > Additionally, we can move the kernel stack very quickly if needed (but it will always take more memory and kva space.) It is even possible to support a dynamic kernel stack. We have been putting together the infrastructure in vm_glue and in pmap to support this for the last 6mos. Setting up the context to support multiple stacks in a process is even simpler (if we need it), all we need to do is to define "what is a stack and where it is", and I can change it in a few hours -- no problem. Don't let what we have stop you from thinking of implementing new things like this -- our VM stuff is basically very flexible. I would like to think that changes like the above are well thought out before we do them though. :-). John