On 03/23/2010 01:13 PM, Jan Kiszka wrote:
The benefit would be that qemu-kvm.git would become a staging tree
instead of the master repository for kvm users. As an example, we
wouldn't have any bisectability problems. kvm features would need to be
written just once.
The last item would imply throwing away what qemu.git already cleaned up
- or finally convert the rest. There is no lazy path.
The code would remain but be disabled (#ifdef KVM_UPSTREAM) (just as
with qemu-kvm.git). The only difference is qemu.git would be usable for
kvm users.
I'd prefer it if the cleanup happened out-of-tree and quickly.
We are more than half-way through this, so let's focus efforts for the
last bits that make the difference widely negligible. This investment
should pay off rather quickly.
If we merge now, we merge the half-completed effort so we don't lose
anything. However, if we can complete the merge quickly, I'm all for
it. I don't want to introduce the ugliness into qemu.git any more than
you do.
One issue of merging blindly is the command line option zoo of qemu-kvm.
I don't think we want this upstream first and then deprecate it quickly
again.
Good point.
Note, the above discussion ignores extboot and device assignment, but
let's focus on the thorny bits first.
I don't think extboot will make it upstream anymore, now that there is
an effort for a gpxe-based virtio boot loader.
Sure, an equivalent is fine.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
