Date: Wed, 18 Sep 1996 22:09:31 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: michaelh@cet.co.jp (Michael Hancock) Cc: terry@lambert.org, dg@Root.COM, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@freebsd.org Subject: Re: thread stacks and protections (was Re: attribute/inode caching) Message-ID: <199609190309.WAA01140@dyson.iquest.net> In-Reply-To: <Pine.SV4.3.93.960919101646.12359A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Sep 19, 96 10:31:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609190309.WAA01140>