Zhang, Xiantao wrote: > Hollis Blanchard wrote: > >> On Mon, 2007-10-08 at 10:36 +0800, Zhang, Xiantao wrote: >> >>> Avi Kivity wrote: >>> >>>> Zhang, Xiantao wrote: >>>> >>>>> Avi Kivity wrote: >>>>> >>>>> >>>>>> Zhang, Xiantao wrote: >>>>>> >>>>>> >>>>>>> Zhang, Xiantao wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Hi Avi, >>>>>>>>> So you mean IA64 can adopt the similar method as well? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> What method do you mean exactly? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Put all arch-specific files into arch/ia64/kvm as you described >>>>>>> in future KVM infrastructure. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The powerpc people had some patches to make kvm_main arch >>>>>>>> independent. We should work on that base. To avoid a dependency >>>>>>>> on the x86 merge, we can start by working withing drivers/kvm/, >>>>>>>> for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. >>>>>>>> Later patches can move these to arch/*/. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> It may work on x86 side. But for IA64, we have several source >>>>>>> files and assembly files to implement a VMM module, which >>>>>>> contains the virtualization logic of CPU, MMU and other platform >>>>>>> devices. (In KVM forum, Anthony had presented IA64/KVM >>>>>>> architecture which is a bit different with x86 side due to >>>>>>> different approaches for VT.).If we put all such these >>>>>>> arch-specific files in one directory, it looks very strange! >>>>>>> >>>>>>> >>>>>>> >>>>>> ia64/ subdirectory is also fine. >>>>>> >>>>>> >>>>> But even so , we have to split current code to be arch-independent, >>>>> and to support IA64 and other architectures. >>>>> So, why not add an more subdirectory x86 in drivers kvm to hold >>>>> X86-arch code? >>>>> >>>>> >>>> Sure, that's not an issue. >>>> >>> Could you help to open a branch from master tree for this work? We >>> are very willing to contribute to it:) >>> >> Do you really need a new branch? Why not just submit patches? >> > > Due to big changes to current source structure, maybe a new branch would > help to work, and doesn't > impact existing quality of KVM. If it is convenient for you to submit > patches directly, also we are glad to do in that way. >
A branch with such large changes quickly becomes out-of-date, so it's best to send patches. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
