Anthony Liguori wrote:
Avi Kivity wrote:
Glauber Costa wrote:
As we're getting close to kvm-xxx anyway, maybe we could forget this
number
scheme, and adopt something that tracks linux. This way, you know
exactly what
kernel a released is based on. Something in the lines of kvm-29.1
for updates
to the .29 series, (of course _this_ scheme is bad, because it
brings clashes)
It also ignores qemu, which is larger contributor to user visible
features...
Maybe stable releases should have separate packages for kvm and qemu:
kvm-modules-2.6.29.1 and qemu-kvm-0.9.1.17. Users would pick the
latest of each, and would only need to upgrade a component that's
changed.
Yes, this would be IMHO the best overall solution. Can we take
kvm-userspace maint/2.6.29 and call it qemu-kvm-0.9.1-1? Most users
don't need newer kernel modules if they have a relatively recent distro.
There's a slight snag here. The kernel module wants bits from the
userspace package (the backward compatibility kit and makefiles); the
userspace package wants some kernel bits (header files).
I think we can work around it by using 'git symbolic-ref'. kvm.git
would have a maint/2.6.29 branch, which would have an alias called
maint/0.9.1. Similarly, kvm-userspace.git would have a branch called
maint/0.9.1, with an alias called maint/2.6.29. Commits into one would
automatically appear on the other.
This sound reasonable?
--
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
