From owner-cvs-all Sun Nov 17 8:53:38 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BAF737B401; Sun, 17 Nov 2002 08:53:37 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09CEF43E75; Sun, 17 Nov 2002 08:53:37 -0800 (PST) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id 7ED0AAE24A; Sun, 17 Nov 2002 08:53:28 -0800 (PST) Date: Sun, 17 Nov 2002 08:53:28 -0800 From: Jon Mini To: Daniel Eischen Cc: Doug Rabson , Alfred Perlstein , Marcel Moolenaar , 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> Mail-Followup-To: Daniel Eischen , Doug Rabson , Alfred Perlstein , Marcel Moolenaar , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org References: <200211171401.02376.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message