WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching

To: Zachary Amsden <zach@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC, PATCH 5/24] i386 Vmi code patching
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Wed, 22 Mar 2006 18:53:36 -0600
Cc: Christopher Li <chrisl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Andi Kleen <ak@xxxxxxx>
Delivery-date: Thu, 23 Mar 2006 00:55:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4421EFD9.8060402@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200603131802.k2DI2nv8005665@xxxxxxxxxxxxxxxxxxx> <200603222115.46926.ak@xxxxxxx> <20060322214025.GJ15997@xxxxxxxxxxxxxxxxxx> <4421EC44.7010500@xxxxxxxxxx> <4421EFD9.8060402@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mail/News 1.5 (X11/20060309)
Zachary Amsden wrote:
Hi Chris,

Would you have less trouble if the "ROM" were actually more like a module? Specifically, if it had a proper elf header and symbol table, used symbols as entry points, and was a GPL interface (so that ROM's had to be GPL)? Then it's just a kernel module that's hidden in the option ROM space and has a C interface.

I know you end up losing the ability to do crazy inlining of the ROM code but I think it becomes a much less hairy interface that way.

Actually, I think you still can get the ability to do crazy inlining of the ROM code. You have three exports from the ELF module:

vmi_init - enter paravirtual mode
vmi_annotate - apply inline transformations based on inlining
vmi_exit - exit paravirtual mode (required for module unloading).

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.

But you can't require the ROM to be GPL'd. It has to be multi-licensed for compatibility with other open source or, even proprietary operating systems. If the ROM is licensed for use only under the GPL, then by including it in your kernel and allowing it to patch your kernel code, you leave your non-GPL kernel in a questionable license state. If the ROM is licensed under an open license, with a clause allowing its inclusion into GPL'd software, then I don't think you have a problem. Course I could be wrong. This is sort of a unique situation, and finding an identical comparison is tricky.

Multi-licensing is fine as long as one is GPL :-)

Regards,

Anthony Liguori

Zach


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>