[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060804214039.GA28508@ti64.telemetry-investments.com>
Date: Fri, 4 Aug 2006 17:40:39 -0400
From: "Bill Rugolsky Jr." <brugolsky@...emetry-investments.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: David Lang <dlang@...italinsight.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Antonio Vargas <windenntw@...il.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Andrew Morton <akpm@...l.org>, jeremy@...source.com,
greg@...ah.com, zach@...are.com, linux-kernel@...r.kernel.org,
torvalds@...l.org, hch@...radead.org, jlo@...are.com,
xen-devel@...ts.xensource.com, simon@...source.com,
ian.pratt@...source.com
Subject: Re: A proposal - binary
On Fri, Aug 04, 2006 at 02:26:20PM -0700, Jeremy Fitzhardinge wrote:
> >I also am missing something here. how can a system be compiled to do
> >several different things for the same privilaged opcode (including
> >running that opcode) without turning that area of code into a
> >performance pig as it checks for each possible hypervisor being present?
>
> Conceptually, the paravirtops structure is a structure of pointers to
> functions which get filled in at runtime to support whatever hypervisor
> we're running over. But it also has the means to patch inline versions
> of the appropriate code sequences for performance-critical operations.
Perhaps Ulrich and Jakub should join this discussion, as the whole
thing sounds like a rehash of the userland ld.so + glibc versioned ABI.
glibc has weathered 64-bit LFS changes to open(), SYSENTER, and vdso.
Isn't this discussion entirely analogous (except for the patching of
performance critical sections, perhaps) to taking a binary compiled
against glibc-2.0 back on Linux-2.2 and running it on glibc-2.4 + 2.6.17?
Or OpenSolaris, for that matter?
Bill Rugolsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists