Avi Kivity wrote:
I was hoping someone (=you) would verify that it means what I think it
means.
I'm the wrong person to ask :-/
In terms of actual releases, I'd really like to see a kvm-0.10.0-0
release based on the qemu-0.10.0 release that didn't contain any
kernel modules.
Pretty soon I'll fork maint/2.6.30, that's a good time for forking
kvm-userspace.git. I could fork at the point qemu-0.10.0 was released.
Unfortunately, the last qemu merge pulled in post-0.10.0 bits. I
guess I could back them out. It isn't going to be pretty.
From a stable maintenance point-of-view, having the kvm stable tree
based on stable_0_10 will make your life a lot easier since you only
have to worry about tracking kvm-specific stable fixes.
Fixing up the tree now will be painful. You could either merge back the
older tree or revert changes in the QEMU tree until you get to
release_0_10_0. Then merging against stable_0_10 would be pretty easy.
None of it is very bisect friendly though :-/
Ideally, we would move libkvm into the qemu tree and collapse the
tree too so it looked very much like qemu does today.
I have a script that takes qemu-userspace.git and rewrites it to
multiple repositories (one per subdirectory, basically, plus one
top-level). That allows us to keep the bios, testsuite, external
module compat kit, etc.
Great. I know you dislike it conceptually, but it's worth considering
splitting out the KVM bios changes into patches as part of the patch
queue that's in qemu SVN. It can potentially help the distros manage
the KVM and QEMU bios builds in the same mechanism.
What do you plan to do about non-stable KVM releases?
Regards,
Anthony Liguori
--
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
