Re: Split kvm source tarballs

[Avi Kivity <avi@redhat.com>]

Christoph Hellwig wrote:
> On Wed, Mar 25, 2009 at 08:44:58AM -0500, Anthony Liguori wrote:
>   
>> 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.
>   

While I strongly dislike duplicating code under source control, I'm 
beginning to lean in this direction, since the situation is beginning to 
confuse me too.

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

We end up with a standalone kvm-userspace.git which is easily mergable 
to and from qemu.git, and kvm.git which can build either a Linux kernel 
(and is easily mergable to and from Linus' tree and others) or an 
external module.

No git submodules or inter-repository dependencies.  What's not to like?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.