Date: Fri, 20 Sep 1996 21:28:22 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: thread stacks and protections (was Re: attribute/inode caching) Message-ID: <Pine.SV4.3.93.960920211346.25361B-100000@parkplace.cet.co.jp> In-Reply-To: <199609191856.LAA01219@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960920211346.25361B-100000>