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.
--
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
