Split kvm source tarballs

As part of the preparations for a formal maintenance branch, we're now providing userspace-only source tarballs and kernel module-only source tarballs. The combined kernel/userspace package is still provided.

Userspace package names will take the form 'qemu-kvm-devel-xx'. Kernel module package names will take the form 'kvm-kmod-devel-xx'. The combined package is named, as usual, kvm-xx'.

When maintenance branch packages become available, -devel will be dropped, of course. Only the split packages will be available for the maintenance branch.

The userspace package can run against modules from the matching kernel module package, or against modules from a released Linux kernel (version 2.6.25 or higher). In almost all cases, you can mix and match userspace and kernel -devel packages.

Please test the release candidates in http://userweb.kernel.org/~avi/kvm-85rc1/ for any packaging errors. Suggestions of any kind are also welcome.

Hrm, I notice that for qemu-kvm, you basically just pulled out the module source.

What do you think about going a step further and building a proper qemu repository?

Quoted 3 lines · Anthony Liguori

Hrm, I notice that for qemu-kvm, you basically just pulled out the module source.

That's step 1.

Quoted 2 lines

What do you think about going a step further and building a proper qemu repository?

Step 2. I have scripts that do that and will merge with Eduardo's script that also rewrites the qemu commit hashes to correspond to qemu.git on git.kernel.org.

That's what I figured. FWIW, the split tarballs work just fine for me.

It may be worth waiting to do step 2 until the IO thread is merged. I think once that happens, we could probably do a sprint to get rid of libkvm in kvm-userspace. That would certainly simplify things.

Quoted 4 lines · Anthony Liguori

That's what I figured. FWIW, the split tarballs work just fine for me.

It may be worth waiting to do step 2 until the IO thread is merged. I think once that happens, we could probably do a sprint to get rid of libkvm in kvm-userspace. That would certainly simplify things.

Yeah. And having the both common and split repos just confuses the heck out of any user of the repository. I think the right way to split it to wait for libkvm going away and just have a qemu-kvm repository and an entirely separate kernel module repository. It's not like there is anything common but the few exported ABI headers, and we can either keep them in both (would mean qemu-kvm can always build against a defined set of headers) or make qemu-kvm require a kernel source like the current kvm support in upstream qemu.

So how about this:

- keep copies of the headers in the qemu repository. 'make sync' becomes a maintainer tool rather than a developer tool

- move qemu to the root of the repository, and reparent libkvm/ user/ and friends under it. this will give us easier merging.

- move the external module kit into kvm.git

Quoted 3 lines

- move qemu to the root of the repository, and reparent libkvm/ user/ and friends under it. this will give us easier merging.

Yeah. While you're at it user/ might be renamed to something more descriptive.

Quoted 2 lines

- move the external module kit into kvm.git

As in your kvm development kernel tree? Not sure it's a good idea to suck this into a full kernel tree. Probably worth making it a small repository of it's own.

If the repo contains only the kit (external-module.h and the hack scripts) we'll be left with dual repositories with their confusion and unbisectability. If the repo contains both the kit and the code, I'll need to commit every kvm.git change into that repository, which I'm sure to botch now and then.

Do you see any specific problem with dropping kvm-userspace.git/kernel/* under kvm.git/scripts/kvm/?

Any idea when the split will happen?

Any idea when the split will happen?

But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace.

Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at ddecccc and then doing a git-svn fetch.

Quoted 4 lines · Anthony Liguori

But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace.

Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at ddecccc and then doing a git-svn fetch.

Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better.

Quoted 4 lines

Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better.

I'm going to switch it to git fwiw.

Quoted 5 lines · Anthony Liguori

Quoted 5 lines

Slightly offtopic, but I always wondered why qemu is hosted in svn. For all project having semi-forks of qemu that they try to keep in sync or even merge back a distributed scm would work so much better.

Quoted 2 lines

I'm going to switch it to git fwiw.

If it's soon enough maybe the kvm repository reorganization should wait for it so that the new repository can be cloned from upstream qemu?

Hi Avi,

I spent some time today putting together an approximation of the KVM stable release based on QEMU 0.10.x. In principle, it's not too bad at all because it's just a matter of creating a branch in kvm-userspace that's based a kvm commit sometime after the QEMU 0.10.x release but before the next qemu-cvs merge you did that happened post QEMU 0.10.x. Basically, it was a merge of 72ee81f and ddecccc.

The problem for me is pulling in the QEMU stable fixes. You don't have a branch that tracks the QEMU stable tree and I can pull in the QEMU stable git tree without rewriting history since the directory layout is different.

But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace.

Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at ddecccc and then doing a git-svn fetch.

Quoted 4 lines · Anthony Liguori

Hi Avi,

I spent some time today putting together an approximation of the KVM stable release based on QEMU 0.10.x. In principle, it's not too bad at all because it's just a matter of creating a branch in kvm-userspace that's based a kvm commit sometime after the QEMU 0.10.x release but before the next qemu-cvs merge you did that happened post QEMU 0.10.x. Basically, it was a merge of 72ee81f and ddecccc.

Quoted 6 lines

The problem for me is pulling in the QEMU stable fixes. You don't have a branch that tracks the QEMU stable tree and I can pull in the QEMU stable git tree without rewriting history since the directory layout is different.

But if you created a qemu-svn-stable branch that followed the QEMU stable tree in kvm-userspace, like the qemu-cvs branch follows trunk, then it would be pretty easy to create and maintain a kvm_stable_0_10 branch of whatever you'd like to call it in kvm-userspace.

Any chance you could do this? I suspect it's just a matter of creating the branch based off of the qemu-cvs tree at ddecccc and then doing a git-svn fetch.

I pushed this under the old naming convention, as kvm-userspace.git maint/2.6.30. I'll rename it once I convert the repo.