On 04.05.2021 20:53, Andrew Cooper wrote: > Unsure what to do about x86_cpu_policies_are_compatible(). It would be nice > to have xc_cpu_policy_is_compatible() sensibly const'd, but maybe that means > we need a struct const_cpu_policy and that smells like it is spiralling out of > control.
Not sure it would be that bad. In fact, looking at the few uses of struct cpu_policy in the hypervisor, I wonder if the two contained pointers couldn't be pointer-to-const right there. Once you've constructed a full struct cpu_policy instance, it shouldn't typically be modified anymore, should it? Would require the respective struct arch_domain fields to also become pointer-to-const. And if the tool stack had any need for a container with pointer-to-non-const, it could locally define a type, keeping lib/x86/ tidy. Jan
