Am 17.01.2013 16:16, schrieb Igor Mammedov:
> Vendor property setter takes string as vendor value but cpudefs> use uint32_t vendor[123] fields to define vendor value. It makes it> difficult to unify and use property setter for values from cpudefs.> > Simplify code by using vendor property setter, vendor[123] fields> are converted into vendor[13] array to keep its value. And vendor> property setter is used to access/set value on CPU.> > - Make for() cycle reusable for the next patch by adding> x86_cpu_vendor_words2str()> > Intel's CPUID spec[1] says:> "> 5.1.1 ...> These registers contain the ASCII string: GenuineIntel> ...> "> > List[2] of known vendor values shows that they all are 12 ASCII> characters long, padded where necessary with space> > Current supported values are all ASCII characters packed in> ebx, edx, ecx. So lets state that qemu supports 12 ASCII characters> packed in ebx, edx, ecx registers for cpuid(0) instruction.> > *1 - http://www.intel.com/Assets/PDF/appnote/241618.pdf> *2 - http://en.wikipedia.org/wiki/CPUID#EAX.3D0:_Get_vendor_ID> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
So, hearing that my suggestion of a union to give us the best of both
worlds did not work out well due to endianness conversions, I would
still like to drop the vendor[0] assertion. And I spot no documentation
for char vendor[...] in this patch, only in the commit message; we could
spare that if we change char vendor[...] array to char *vendor, what do
you think? Erroring out (or padding) could be done when setting it via
"vendor" property onto X86CPU (maybe I'll try to cook up something for
demonstration).
Regards,
Andreas