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 <imamm...@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 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
