Date: Tue, 08 Dec 1998 00:28:11 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> Cc: zhihuizhang <bf20761@binghamton.edu>, hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Definition of kstack and PTDpde in locore.s Message-ID: <199812071628.AAA19880@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 07 Dec 1998 10:07:51 GMT." <Pine.BSF.4.01.9812071001400.448-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > On Sun, 6 Dec 1998, zhihuizhang wrote: [..] > > Is this in the 2.2 source tree? We used to put the kernel stack of all > processes at the same virtual address (traditionally the struct user for > each process which includes the stack was always mapped in the same place > and could be accessed using the global variable 'u'). I think that with > the definition: > > .set _kstack, USRSTACK > > then from C, you could have: > > extern char kstack[]; > > assert(&kstack[0] == (char*) USRSTACK); > > i.e. to find the top of the kernel stack, take the address of kstack. > > For the 3.0 line, the virtual address of the struct user is different for > each process which makes some things easier (debugging and probably SMP I > guess) at the expense of using two pages of the kernel's virtual address > space per process. For 2.2, we have it mapped twice, once at the fixed virtual address in process space, as well as the two pages in kernel space. The 3.0 change was to remove the stack from the user space in order to allow address space sharing for thread support. However, this probably has to change. What we really need is a fixed kernel address space for the kstack, and an alternate kstack to be mappable (think ptrace etc, registers on another process at the time of a trap may (I think) be on it's kstack. This could be wrong, it's a while since I looked). This way an address space could be shared thousands of times without using '"thousands" times 2' pages of KVM space. This would go part of the way towards solving a few outstanding problems with address space sharing (rfork/ threading) with SMP too. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812071628.AAA19880>