Re: [libvirt] [PATCH 0/4] cpu: modularize the CPU map data file
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list