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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
