Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161527AbWHDWNM (ORCPT ); Fri, 4 Aug 2006 18:13:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161529AbWHDWNM (ORCPT ); Fri, 4 Aug 2006 18:13:12 -0400 Received: from mga06.intel.com ([134.134.136.21]:65121 "EHLO orsmga101.jf.intel.com") by vger.kernel.org with ESMTP id S1161527AbWHDWNM (ORCPT ); Fri, 4 Aug 2006 18:13:12 -0400 X-IronPort-AV: i="4.07,213,1151910000"; d="scan'208"; a="102859066:sNHT1784809880" Message-ID: <44D3C37F.7020803@linux.intel.com> Date: Fri, 04 Aug 2006 15:00:31 -0700 From: Arjan van de Ven User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Lang CC: Antonio Vargas , Rusty Russell , Andrew Morton , jeremy@xensource.com, greg@kroah.com, zach@vmware.com, linux-kernel@vger.kernel.org, torvalds@osdl.org, hch@infradead.org, jlo@vmware.com, xen-devel@lists.xensource.com, simon@xensource.com, ian.pratt@xensource.com, jeremy@goop.org Subject: Re: A proposal - binary References: <44D1CC7D.4010600@vmware.com> <20060803190605.GB14237@kroah.com> <44D24DD8.1080006@vmware.com> <20060803200136.GB28537@kroah.com> <44D2B678.6060400@xensource.com> <20060803211850.3a01d0cc.akpm@osdl.org> <1154667875.11382.37.camel@localhost.localdomain> <20060803225357.e9ab5de1.akpm@osdl.org> <1154675100.11382.47.camel@localhost.localdomain> <69304d110608041146t44077033j9a10ae6aee19a16d@mail.gmail.com> <44D39F73.8000803@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1350 Lines: 30 David Lang wrote: > On Fri, 4 Aug 2006, Arjan van de Ven wrote: > >> David Lang wrote: >>> I'm not commenting on any of the specifics of the interface calls (I >>> trust you guys to make that be sane :-) I'm just responding the the >>> idea that the interface actually needs to be locked down to an ABI as >>> opposed to just source-level compatability. >> >> you are right that the interface to the HV should be stable. But those >> are going >> to be specific to the HV, the paravirt_ops allows the kernel to >> smoothly deal >> with having different HV's. >> So in a way it's an API interface to allow the kernel to deal with >> multiple >> different ABIs that exist today and will in the future. > > so if I understand this correctly we are saying that a kernel compiled > to run on hypervisor A would need to be recompiled to run on hypervisor > B, and recompiled again to run on hypervisor C, etc > no the actual implementation of the operation structure is dynamic and can be picked at runtime, so you can compile a kernel for A,B *and* C and at runtime the kernel picks the one you have - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/