Ian Campbell wrote:
> On Mon, 2012-11-26 at 22:28 +0000, Jim Fehlig wrote:
>
>> @@ -62,6 +63,52 @@ struct guest_arch {
>> static const char *xen_cap_re = "(xen|hvm)-[[:digit:]]+\
>> \.[[:digit:]]+-(x86_32|x86_64|ia64|powerpc64)(p|be)?";
>> static regex_t xen_cap_rec;
>>
>> +/*
>> + * Copied from split_string_into_string_list() in
>> + * $xen-sources/tools/libxl/xl_cmdimpl.c, which is licensed LGPL v2.1.
>> + */
>>
>
> Looks like I am the sole author of that original function
> (24250:71ecbef5645f xen-unstable.hg). I'd more than likely be happy to
> relicence under whatever terms would be suitable for libvirt -- what are
> they?
>
> In particular I'd be happy with LGPL v2.1+ if that's what it takes.
>
In the meantime, Daniel introduced some string utilities in libvirt,
including virStringSplit(), so I've dropped the copied code.
>
>> +static int
>> +libxlSplitStringIntoStringList(const char *str,
>> + const char *delim,
>> + libxl_string_list *psl)
>>
> [...]
>
>
>> @@ -393,26 +458,25 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, libxl_domain_config *d_config)
>> int hvm = STREQ(def->os.type, "hvm");
>> int i;
>>
>> - /* Currently, libxenlight only supports 32 vcpus per domain.
>> - * cur_vcpus member of struct libxl_domain_build_info is defined
>> - * as an int, but its semantic is a bitmap of online vcpus, so
>> - * only 32 can be represented.
>> + /*
>> + * libxl in Xen 4.2 supports up to 128 vcpus, cur_vcpus was replaced
>> + * by avail_vcpus of type libxl_bitmap
>>
>
> Do you happen to know where the 128 number comes from? I think libxl is
> mostly agnostic about the size of this bitmap and should just be
> exposing whatever the hypervisor supports.
>
I've also removed this check and sent a v2.
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list