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

[Anthony Liguori <aliguori@us.ibm.com>]

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