Date: Sun, 17 Nov 2002 08:53:28 -0800 From: Jon Mini <mini@freebsd.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Doug Rabson <dfr@nlsystems.com>, Alfred Perlstein <bright@mu.org>, Marcel Moolenaar <marcel@xcllnt.net>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc_r/arch/ia64 _atomic_lock.S Message-ID: <20021117165328.GE2070@elvis.mu.org> In-Reply-To: <Pine.GSO.4.10.10211171051480.16958-100000@pcnet1.pcnet.com> References: <200211171401.02376.dfr@nlsystems.com> <Pine.GSO.4.10.10211171051480.16958-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen [eischen@pcnet1.pcnet.com] wrote : > On Sun, 17 Nov 2002, Doug Rabson wrote: > > This is a bit different - I'm talking about the ia64's register stack, > > as distinct from its normal stack. When switching from one thread to > > another, you must flush any dirty registers into the old thread's > > register stack backing memory. Doing this from kernel mode can be > > tricky since the pages of backing memory might not be valid yet. > > Just curious, how do you intend to work this into things > for which the specs allow one stack? pthread_attr_setstackaddr, > pthread_attr_setstacksize, makecontext, etc. > > Do the stacks grow in different directions so that you could > use one chunk of memory with one stack starting at the top > and the other at the bottom, so they would grow towards > each other (perhaps with a guard page in between)? Yes. =) That's why moving to the stack_t stuff was so important. Now every standardized MI API uses a stack_t, which provides the MD code with both the top and bottom of the memory region. -- Jonathan Mini <mini@freebsd.org> http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021117165328.GE2070>