Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
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?
That's close to sounding like git-giberish to me but if you think
it'll do what you want it to do then it works for me :-)
I was hoping someone (=you) would verify that it means what I think it
means.
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.
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.
--
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
