From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932152AbWCWBB1 (ORCPT ); Wed, 22 Mar 2006 20:01:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932165AbWCWBB1 (ORCPT ); Wed, 22 Mar 2006 20:01:27 -0500 Received: from mailout1.vmware.com ([65.113.40.130]:33553 "EHLO mailout1.vmware.com") by vger.kernel.org with ESMTP id S932152AbWCWBB0 (ORCPT ); Wed, 22 Mar 2006 20:01:26 -0500 Message-ID: <4421F34F.6030300@vmware.com> Date: Wed, 22 Mar 2006 17:01:03 -0800 From: Zachary Amsden User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Anthony Liguori Cc: Chris Wright , Xen-devel , virtualization@lists.osdl.org, Linux Kernel Mailing List , Christopher Li , Wim Coekaerts , Andi Kleen , Chris Wright , Linus Torvalds , Anne Holler , Jan Beulich , Jyothy Reddy , Kip Macy , Ky Srinivasan , Leendert van Doorn Subject: Re: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching References: <200603131802.k2DI2nv8005665@zach-dev.vmware.com> <200603222115.46926.ak@suse.de> <20060322214025.GJ15997@sorel.sous-sol.org> <4421EC44.7010500@us.ibm.com> <4421EFD9.8060402@vmware.com> <4421F190.2050908@us.ibm.com> In-Reply-To: <4421F190.2050908@us.ibm.com> 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 Anthony Liguori wrote: > > Hrm, I was actually thinking that each of the VMI calls would be an > export (vmi_init, vmi_set_pxe, etc.). I know that you want the > hypervisor to drive the inlining but I that's sufficiently hairy (not > to mention, there's not AFAIK performance data yet to justify it) that > I think it ought to be left for VMI 2.0. That seems quite ok to me. It is a little weird to have the VMI calls be an export when some of them really can never be properly callable C functions, and you have to overwrite the native code, so the linking step is .. well this magic disassembly glue again. But it could be made to work, and we have discussed it before. > Multi-licensing is fine as long as one is GPL :-) I agree. But it sort of defeats the point of the GPL if you can optionally redistribute the code under the BSD license as well. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: Re: [RFC, PATCH 5/24] i386 Vmi code patching Date: Wed, 22 Mar 2006 17:01:03 -0800 Message-ID: <4421F34F.6030300@vmware.com> References: <200603131802.k2DI2nv8005665@zach-dev.vmware.com> <200603222115.46926.ak@suse.de> <20060322214025.GJ15997@sorel.sous-sol.org> <4421EC44.7010500@us.ibm.com> <4421EFD9.8060402@vmware.com> <4421F190.2050908@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4421F190.2050908@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: Christopher Li , Xen-devel , Chris Wright , Linux Kernel Mailing List , Jan Beulich , Wim Coekaerts , Chris Wright , virtualization@lists.osdl.org, Linus Torvalds , Anne Holler , Jyothy Reddy , Kip Macy , Ky Srinivasan , Leendert van Doorn , Andi Kleen List-Id: xen-devel@lists.xenproject.org Anthony Liguori wrote: > > Hrm, I was actually thinking that each of the VMI calls would be an > export (vmi_init, vmi_set_pxe, etc.). I know that you want the > hypervisor to drive the inlining but I that's sufficiently hairy (not > to mention, there's not AFAIK performance data yet to justify it) that > I think it ought to be left for VMI 2.0. That seems quite ok to me. It is a little weird to have the VMI calls be an export when some of them really can never be properly callable C functions, and you have to overwrite the native code, so the linking step is .. well this magic disassembly glue again. But it could be made to work, and we have discussed it before. > Multi-licensing is fine as long as one is GPL :-) I agree. But it sort of defeats the point of the GPL if you can optionally redistribute the code under the BSD license as well.