[libvirt] [PATCH 0/4] cpu: modularize the CPU map data file
John Ferlan
jferlan at redhat.com
Tue Aug 14 12:21:40 UTC 2018
On 08/14/2018 05:00 AM, Jiri Denemark wrote:
> On Wed, Aug 01, 2018 at 18:02:28 +0100, Daniel P. Berrangé wrote:
>> Currently we have a cpu_map.xml file that contains all the features and
>> CPU models for all architectures in one place. I frequently find myself
>> wondering about the differences between CPU models, but it is hard to
>> compare them as the list of features is huge.
>>
>> With this patch series we end up with a large set of small files, one
>> per named CPU model, along with one for the feature and vendor
>> definitions
>>
>> cpu_map_ppc64_POWER6.xml
>> cpu_map_ppc64_POWER7.xml
>> cpu_map_ppc64_POWER8.xml
>> cpu_map_ppc64_POWER9.xml
>> cpu_map_ppc64_POWERPC_e5500.xml
>> cpu_map_ppc64_POWERPC_e6500.xml
>> cpu_map_ppc64_vendors.xml
>> cpu_map_x86_486.xml
>> cpu_map_x86_athlon.xml
>
> Could we make a cpu_map subdirectory and create the CPU definitions
> there instead? For example
>
> src/cpu_map/ppc64_POWER6.xml
> src/cpu_map/x86_Broadwell-IBRS.xml
Hmm... The cpu_map or even some sort of 'arch' based subdirectory naming
scheme could be useful... If it was src/cpu/cpu_map/ppc64/ and
src/cpu/cpu_map/x86/, then for each .xml file in the @arch subdirectory
type logic is possible, but that could possibly "miss" something that
was 'previously available' from the parent cpu_map.xml file too since
the include could have a directory or arch attribute rather than
filename attribute. Is deleting a CPU a problem? Surely it'd make adding
a new CPU easier since it would simply be adding a new file and no need
to also add the include filename= to the main map.
John
>
> I think it would make navigation through both the sources and the CPU
> models a lot easier.
>
> Jirka
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
More information about the libvir-list
mailing list