On Tue, Aug 14, 2018 at 08:21:40 -0400, John Ferlan wrote:
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.
I think we can still keep the <include filename="..."/> elements even after moving the files into separate directory(ies). Adding a new file is not that frequent to be worth optimizing by loading all files automatically. And explicit includes makes possible issues with missing files, wrong permissions, etc. easier to spot. Jirka