On 18/12/2016 21:20, "Haozhong Zhang" <haozhong.zh...@intel.com> wrote:
>On 12/16/16 19:03 +0000, Andrew Cooper wrote:
>>On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>>b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 0000000..e1a6ef8
>>> --- /dev/null
>>> +++ b/include/arch/x86/hvm/vmx/vmcs.h
>>> @@ -0,0 +1,179 @@
>>> +#ifndef XTF_X86_HVM_VMX_VMCS_H
>>> +#define XTF_X86_HVM_VMX_VMCS_H
>>> +
>>> +/* VMCS field encodings. */
>>> +#define VMCS_HIGH(x) ((x) | 1)
>>> +enum vmcs_field {
>>> + VIRTUAL_PROCESSOR_ID = 0x00000000,
>>> + POSTED_INTR_NOTIFICATION_VECTOR = 0x00000002,
>>> + EPTP_INDEX = 0x00000004,
>>> +#define GUEST_SEG_SELECTOR(sel) (GUEST_ES_SELECTOR + (sel) * 2) /* ES
>>>... GS */
>>
>>Unfortunately, there is probably a BSD/GPL licensing issue here.
>>
>>XTF is BSD clause 2 licensed, because a lot of the core microkernel bits
>>are generally useful to other microkernel projects, and I have specific
>>plans to contribute improvements back to the likes of Mini-OS and
>>HVMLoader. I would specifically like to maintain this property.
>>
>>Xen, following its Linux heritage, is strictly GPLv2 (other than the
>>public headers, which are specifically different).
>>
>>
>>Having XTF use the same naming as Xen is convenient for development, and
>>I specifically don't want to get caught up in tricks like renaming
>>constants;
>
>but renaming or taking names from other BSD-licensed projects [1] could
>keep the whole project as purely BSD-licensed.
>
>[1]
>https://github.com/freebsd/freebsd/blob/master/sys/amd64/vmm/intel/vmcs.h
I am not sure what you mean.
>> these names inherit from the architecture manual and calling
>>them anything else would be even worse. If we were to go down this
>>route, being able to keep the header file in sync would be useful, but
>>dual licensing it Xen would be complicated and confusing.
>>
>>BSD and GPL are compatible licenses. One option Ian suggested would be
>>to have a GPL subdirectory in XTF which clearly separates GPL content
>>from BSD content. The resulting tests would become GPL, but the primary
>>distribution method is "git clone && make", so there are no issues
>>there.
This seems to be a workable approach.
Whether the test suite itself (when combined with minios or other non-GPL
baselines) are GPL or another license probably does not matter.
Separating the GPL code out, would be useful if the suite needed to be
combined with a baseline which is non-GPL compatible.
@Andy: you may want to have a chat with Ian and check whether the MPL 2.0
may be a better choice for XTF than BSD in this case. I have not looked
into how copyleft and MPL 2 work together though. Just a thought.
>If I want to use the BSD-licensed files individually in other
>projects, will I need to keep a GPL license with them?
I am assuming you mean whether the file needs a GPL (c) header? The answer
is no.
But the combined work will be GPL: for example let's say a folder A has
BSD files in it and a folder B has GPL files in it and you compile A and B
together to AB.exe, then AB.exe as a whole is licensed under the GPL.
>
>Thanks,
>Haozhong
>
>> I think it is reasonable to take this approach for header file
>>content like this, describing an external ABI, but I'd certainly like to
>>avoid doing anything similar for other content, as it complicates
>>contributing microkernel content back to other projects.
>>
>>CC'ing various people for opinions.
>>
>>~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
