[libvirt] [PATCH 0/4] cpu: modularize the CPU map data file

[John Ferlan]

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
>