From: "Jan Beulich" Subject: Re: [PATCH 2/10] linux 2.6.18: COMPAT_VDSO Date: Fri, 09 Mar 2007 10:17:33 +0000 Message-ID: <45F1424D.76E4.0078.0@novell.com> References: <45EC3BE9.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: jeremy@goop.org, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 05.03.07 16:55 >>> >On 5/3/07 14:48, "Jan Beulich" wrote: > >> It's gonna be really old libc-s that need an absolutely invariable address. >> But >> you certainly recall that in 2.6.16 (and probably earlier) we had a hack to >> map >> it in right below PAGE_OFFSET, which worked too for not really new but also >> not really old libc-s. It is those intermediate libc (supporting AT_SYSINFO >> but >> not AT_SYSINFO_EHDR) versions that the option attempts to address for >> Xen. I happen to have a SuSE 9.0 system still in active use that doesn't work >> without this option, and I think glibc 2.3.2 shouldn't be considered entirely >> obsolete, yet. > >The build-system approach looks simplest (certainly smaller than the C code) >but is impenetrable to read. I think we'd take that approach if you add some >comments to explain what's going on in the makefile runes. I didn't follow up on this so far because kernel mainline seems to want the fix for paravirt guests, too, but seems more favorable of the C approach. I haven't seen anything new on this during the last two days anymore, so would want to re-inquire whether you wouldn't then change your mind on which approach to take. Jan