* Jes Sorensen<Jes.Sorensen@xxxxxxxxxx> wrote:[...]
At my previous employer we ended up dropping all Xen efforts exactly because
it was like maintaining two separate operating system kernels. The key to
KVM is that once you have Linux, you practically have KVM as well.
Yes. Please realize that what is behind it is a strikingly simple argument:
"Once you have a single project to develop and maintain all is much better."
[...] However, there is far more to it than just a couple of ioctls, for
example the stack of reverse device-drivers is a pretty significant code
base, rewriting that and maintaining it is not a trivial task. It is
certainly my belief that the benefit we get from sharing that with QEMU by
far outweighs the cost of forking it and keeping our own fork in the kernel
tree. In fact it would result in exactly the same problems I mentioned above
wrt Xen.
I do not suggest forking Qemu at all, i suggest using the most natural
development model for the KVM+Qemu shared project: a single repository.
With this you have just thrown away all the benefits of having the QEMU
repository shared with other developers who will actively fix bugs in
components we do care about for KVM.
Not if it's a unified project.
- encourage kernel-space and user-space KVM developers to work on both
user-space and kernel-space bits as a single unit. It's one project and
a single experience to the user.
This is already happening and a total non issue.
My experience as an external observer of the end result contradicts this.
Seemingly trivial usability changes to the KVM+Qemu combo are not being done
often because they involve cross-discipline changes.
- [ and probably libvirt should go there too ]
Now that would be interesting, next we'll have to include things like libxml
in the kernel git tree as well, to make sure libvirt doesn't get out of sync
with the version supplied by your distribution vendor.
The way we have gone about this in tools/perf/ is similar to the route picked
by Git: we only use very lowlevel libraries available everywhere, and we
provide optional wrappers to the rest.
So far your argument would justify pulling all of gdb into the kernel git
tree as well, to support the kgdb efforts, or gcc so we can get rid of the
gcc version quirks in the kernel header files, e2fsprogs and equivalent for
_all_ file systems included in the kernel so we can make sure our fs tools
never get out of sync with whats supported in the kernel......
gdb and gcc is clearly extrinsic to the kernel so why would we move them
there?
I was talking about tools that are closely related to the kernel - where much
of the development and actual use is in combination with the Linux kernel.
90%+ of the Qemu usecases are combined with Linux. (Yes, i know that you can
run Qemu without KVM, and no, i dont think it matters in the grand scheme of
things and most investment into Qemu comes from the KVM angle these days. In
particular it for sure does not justify handicapping future KVM evolution so
drastically.)
Oh and you completely forgot SeaBIOS. KVM+QEMU rely on SeaBIOS too, so from
what you're saying we should pull that into the kernel git repository as
well. Never mind the fact that we share SeaBIOS with the coreboot project
which is very actively adding features to it that benefit us as well.....
SeaBIOS is in essence a firmware, so it could either be loaded as such.
Just look at the qemu source code - the BIOSes are .bin images in
qemu/pc-bios/ imported externally in essence.
qemu-kvm branch is not similar to my proposal at all: it made KVM _more_
fragmented, not more unified. I.e. it was a move in the exact opposite
direction and i'd expect such a move to fail.
In fact the failure of qemu-kvm supports my point rather explicitly: it
demonstrates that extra packages and split development are actively harmful.
I speak about this as a person who has done successful unifications of split
codebases and in my judgement this move would be significantly beneficial to
KVM.
You cannot really validly reject this proposal with "It wont work" as it
clearly has worked in other, comparable cases. You could only reject this with
"I have tried it and it didnt work".
Think about it: a clean and hackable user-space component in tools/kvm/. It's
very tempting :-)