On 01/10/2010 04:28 PM, Gleb Natapov wrote:
On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
In order to improve qemu.git kvm integration quality wrt
performance, features, and reliability Marcelo and I will begin to
maintain a patch queue based on qemu.git containing kvm-related
patches. We will review and apply patches to this queue, test them
using the same test suite that is used for qemu-kvm.git, and
regularly submit them for inclusion in qemu.git, mimicking the
relationship between kvm.git and Linus' linux-2.6.git.
One of the problems of qemu.git kvm support is that it is a clean
reimplementation, and thus some of the nuances that were carefully
ironed out in qemu-kvm.git are lost. To that end, we would like to
change the process of adding features as follows:
- first, the feature in qemu-kvm.git master is morphed to a form
suitable for merging into qemu.git
- when that has been accomplished, the feature is broken into
patches and merged into the patch queue
If there is the same feature in qemu-kvm.git and qemu.git whom is morphed to
whom and who is merged where? I am confused. We have much of duplicated
code between qemu-kvm.git and qemu.git it is often almost, but not exactly the
same. Is it really productive to set rules who should be morphed and how
at this point?
If the feature is already in both, then morph qemu-kvm.git into what is
already in qemu.git. Hopefully anything missing in qemu.git will be
discovered while making the changes.
In order to get a kvm feature into qemu.git, please observe the
following process:
- post a patch series against qemu-kvm.git/master that implements
the feature, or changes an existing feature to use qemu.git
infrastructure
It was other way around till last week. Why change?
There were a lot of regressions.
--
error compiling committee.c: too many arguments to function
--
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
