On Thu, 2008-09-18 at 15:20 +0800, Liu Yu wrote: > This patch gives a example of refactor, which is derived from x86. > It aims at collecting comments. Thanks for sending this Yu. I needed some more extensive code refactoring work for another processor I'm looking at (I'll send patches shortly), but this approach is still needed to divide struct kvm_vcpu_arch. I will look at adapting this patch on top of the other refactoring I've done. > I have not even tried to build it, for I have no 440 toolchain. > I can test it on E500, but it needs some time to move E500 code base on it. > > Hollis, > > 1. Do we need to move 44x_tlb.c into 44x.c? > so that some special struct definition can be moved from kvm_host.h to 44x.c/.h. Yeah, we definitely need a 44x.c, but I think also a 44x_tlb.c and 44x_emulate.c to keep it from growing too large. > 2. We could adopt the ops method like x86, > then kvm for different cores can be dynamicly inserted as a module, > or adopt static compile method like current kvmppc. > How do you think of it. Well, unlike Intel/AMD, we can't have a single binary for any of our processors (440, e500, e500mc, future). Even e500 and e500mc can't both be supported in a single binary kernel, right? Given that, I don't think function pointers are the right approach. -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
