On 03/02/2010 02:30 AM, Ingo Molnar wrote:
* Anthony Liguori<anthony@xxxxxxxxxxxxx> wrote:
On 03/01/2010 02:56 PM, Ingo Molnar wrote:
Here's our experience with tools/perf/. Hosting the project in the kernel
proper helped its quality immensely:
- It's much easier to synchronize new features on the kernel side and on the
user-space side. The two go hand in hand - they are often implemented in
the same patch.
Kernel features and qemu features usually don't have a great amount of
intersect. All of the problems you've described are strictly in the qemu
space.
IMO that's a bug, not a feature. There should be a lot more interaction
between kvm-qemu and KVM: for example Qemu should have a feature to install
paravirt drivers in the guest, this would be helped by living in the kernel
repo.
The paravirt drivers are completely disassociated from kvm. You can run
a virtio driver with qemu but without kvm (or even with virtualbox,
without either qemu or kvm).
For Linux, installing drivers automatically in older guests is
impossible due to Documentation/stable_api_nonsense.txt and unnecessary
in newer Linux (same reason). For non-Linux, this feature certainly
makes sense, but I don't see how putting qemu in tools/kvm helps it much.
- It's released together with the kernel, which gives a periodic 3 months
release frequency. Not too slow, not too fast.
qemu release range in length from 3-6 months depending on
distribution schedules. They are very regular.
The Linux kernel is released every 3 months, +- one week. Our experience is
that even 6 months would be (way) too painful for distros.
It would also be horrible for internal synchronization. That's not an
issue with qemu, nor do I think that six months would hurt distros any.
In any case, we respond to feedback (which we happen to generate in the
first place).
- Code quality requirements are that of the kernel's. No muck allowed and
it's not hard to explain what kind of code is preferred.
Code quality is subjective. We have a different coding style.
That's somewhat of a problem when for example a KVM kernel-space developer
crosses into Qemu code and back. Two separate styles, etc. I certainly
remember a 'culture clash' when going from the kernel into Qemu and back.
Different principles, different culture. It's better to standardize.
That sounds like a trivial thing.
- Tool breakage bisection is a breeze: there's never any mismatch between
tools/perf and the kernel counterpart. With a separate package we'd
have more complex test and bisection scenarios.
KVM has a backwards compatible ABI so there's no such thing as mismatch
between user and kernel space.
perf too is ABI compatible (between releases) - still bisection is a lot
easier because the evolution of a particular feature can be bisected back to.
Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even
of released versions. Also, within a development version you sure sometimes
iterate a new ABI component, right? With a time-coherent repository both
intentional and unintentional breakages and variations can be bisected back to
as they happened.
This is an unconditional advantage and i made use of it numerous times.
Try old qemu on new kernel. If it works, bisect qemu. If it fails,
bisect the kernel.
If you're lucky it is qemu that was broken, so no kernel rebuilds and
reboots. Since qemu is much larger than kvm, it is more likely to have
introduced the problem, so the bisect goes faster.
You could argue that any project should be in the kernel for these
reasons. I see no reason why something as like KVM should be part
of the kernel and udev shouldn't be.
Yes, you are quite correct: udev has been argued to be a prime candidate for
tools/. (and some other kernel utilities as well)
From a design POV all 'system/kernel utilities', which make little sense
without the kernel and are license compatible can (and arguably should) move
there.
Obviously there's no pressure to do so - it's only an opportunity.
Only a small part of qemu, especially the desktop oriented qemu that you
seem to want, actually interfaces with kvm. Mostly it involves
emulating hardware, issuing I/O, talking to management layers,
presenting a user interface, etc. It's not a system/kernel utility.
etc.
In the KVM context this was obviously only a suggestion though. If i were
hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project
has very close ties to kernel-KVM and repo level unification would create
various synergies - but you are hacking on it, not me ;-)
If i were doing it i'd probably start with a cleaned up and stripped down
version of Qemu, to make it eligible for mainline kernel inclusion.
You should try it. I think you'll find that it's not as obvious thing to do
as you think it is.
A few years ago I looked into cleaning up Qemu, when i hacked KVM and Qemu. I
also wanted to have a 'qemu light', which is both smaller and cleaner, and
still fits to KVM. It didnt look particularly hard back then - but it's
certainly not zero amount of work.
Cleanups pay - they make a piece of code both more hackable, more debuggable
and more appealing to new developers. (i suspect you have no argument with
that notion) Also note that it wasnt me who suggested that Qemu wouldnt fit
the kernel standards as-is - it was raised by others in this discussion.
I'm sure patches to clean up qemu will be more than welcome on qemu-devel.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
