* Avi Kivity wrote: > Carsten Otte wrote: > > Hollis Blanchard wrote: > >> These patches are based on Xiantao's work to create struct kvm_x86. > >> Patch 1 replaces his "KVM Portability split: Splitting kvm structure > >> (V2)", and patches 2 and 3 build on it. > > > > Looks like a clean approach with to to_kvm_x86 macro. Whole series: > > Acked-by: Carsten Otte <[EMAIL PROTECTED]> > > Well, I hate to say it, but the resulting code doesn't look too well > (all the kvm_x86 variables), and it's entirely my fault as I recommended > this approach. Not like it was difficult to predict. > > I'm thinking again of > > struct kvm { > struct kvm_arch a; > ... > } > > Where each arch defines its own kvm_arch. Now the changes look like a > bunch of "kvm->blah" to "kvm->a.blah" conversions.
I was thinking the exact same thing. Having an arch-specific kvm as the super-structure decouples 'struct kvm' from everything and it's extremely clumsy to look at and program with. container_of() for getting struct kvm might be better than getting the arch-specific thing. > > IIRC a downside was mentioned that it is easier to cause a build failure > for another arch now. How? I think it would work the same way in either case. Any arch-specific stuff happen in kvm_arch and generic stuff in kvm. > > Opinions? In theory correctness should win over style every time, no? But are those two conflicting here? And if you don't like what you're looking at, it's going to be tougher to make it correct without making it look better ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel