(if-else forest is daunting.)
I think this approach is quite acceptable, except that there will be many
if-else in the code. Not clean enough.
(b) Convert intel-pmu.c => vmx.c and convert amd-pmu.c => svm.c
* PMU function pointers will be created in kvm_x86_ops;
* The entry functions will be created inside vmx.c and svm.c respectively;
I would be nicer to keep them in separate files and link to vmx/svm.
* There might be common functions defined in pmu.c.
This design is viable too. But to be honest, it is a bit messy compared with
(a).
This makes sense as we will use only vmx+intel_pmu and svm+amd_pmu, so
we'd have less code loaded in both cases.
I consider design (c) strictly better than the current one (2):
(c) keep {intel,amd}-pmu.c and introduce pmu.[hc] that joins duplicate
functions and wraps kvm_pmu_ops
Thanks for the suggestion. I will take this into consideration. Your
suggestion is similar to existing svm.c/vmx.c/x86.c, which split
distinct functions in vmx.c/svm.c; but in the meanwhile merging them in
x86.c for common code.
And if we decide to move VMX/SVM related code into their respective
modules, we won't have to change callers.
Yes.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
