On 05/03/2013 07:17 AM, Eduardo Habkost wrote:
>
> We could, but maybe it would make the interface harder to use and not
> easier?
>
> Even when two feature words are returned in the same CPUID leaf, they
> are independent and separate feature-words that must be checked
> individually by libvirt, so I believe returning one feature-word per
> array-item makes more sense. Having an extra item in the array would
> make it clear for libvirt that QEMU has a new feature-word that libvirt
> doesn't know about, and easier to spot than an extra field in an
> existing array item.
Firmly agree - bundling multiple features into one array item is not nice.
>
>
>> item[5].CPUID: EAX=7h,ECX=0h
>
> What would be the data type of this "CPUID" field? Are you suggesting
> returning a string to be parsed manually?
Anything that requires parsing to break into pieces on the receiving end
implies that it was not correctly represented in JSON in the first
place. I'd much rather see it kept as multiple fields.
>>> + for (w = 0; w < FEATURE_WORDS; w++) {
>>> + FeatureWordInfo *wi = &feature_word_info[w];
>>> + X86CPUFeatureWordInfo *qwi = &word_infos[w];
>>> + qwi->cpuid_input_eax = wi->cpuid_eax;
>>> + qwi->has_cpuid_input_ecx = wi->cpuid_needs_ecx;
>>> + qwi->cpuid_input_ecx = wi->cpuid_ecx;
>>> + qwi->cpuid_register = x86_reg_info_32[wi->cpuid_reg].qapi_enum;
>> Is there way not to use qapi_enum at all and use name instead?
>
> Are you suggesting making the qapi interface be string-based instead of
> using an enum? Why?
enum-based is better than string based. That way, when we add
introspection in qemu 1.6, libvirt can see what enum values to expect,
instead of having an open-ended set of strings with no idea what strings
will be present.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list