[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project
On 03/18/2010 03:31 PM, Ingo Molnar wrote:
> * Avi Kivity<> wrote:
>> On 03/18/2010 03:02 PM, Ingo Molnar wrote:
>>>> [...] What users eagerly replace their kernels?
>>> Those 99% who click on the 'install 193 updates' popup.
>> Of which 1 is the kernel, and 192 are userspace updates (of which one may be
>> qemu).
> I think you didnt understand my (tersely explained) point - which is probably
> my fault. What i said is:
> - distros update the kernel first. Often in stable releases as well if
> there's a new kernel released. (They must because it provides new hardware
> enablement and other critical changes they generally cannot skip.)

No, they don't. RHEL 5 is still on 2.6.18, for example. Users don't
like their kernels updated unless absolutely necessary, with good reason.

Kernel updates = reboots.

> - Qemu on the other hand is not upgraded with (nearly) that level of urgency.
> Completely new versions will generally have to wait for the next distro
> release.

F12 recently updated to 2.6.32. This is probably due to 2.6.31.stable
dropping away, and no capacity at Fedora to maintain it on their own.
So they are caught in a bind - stay on 2.6.31 and expose users to
security vulnerabilities or move to 2.6.32 and cause regressions. Not a
happy choice.

> With in-kernel tools the kernel and the tooling that accompanies the kernel
> are upgraded in the same low-latency pathway. That is a big plus if you are
> offering things like instrumentation (which perf does), which relates closely
> to the kernel.
> Furthermore, many distros package up the latest -git kernel as well. They
> almost never do that with user-space packages.

I'm sure if we ask the Fedora qemu maintainer to package qemu-kvm.git
they'll consider it favourably. Isn't that what rawhide is for?

> Let me give you a specific example:
> I'm running Fedora Rawhide with 2.6.34-rc1 right now on my main desktop, and
> that comes with perf-2.6.34-0.10.rc1.git0.fc14.noarch.
> My rawhide box has qemu-kvm-0.12.3-3.fc14.x86_64 installed. That's more than a
> 1000 Qemu commits older than the latest Qemu development branch.
> So by being part of the kernel repo there's lower latency upgrades and earlier
> and better testing available on most distros.
> You made it very clear that you dont want that, but please dont try to claim
> that those advantages do not exist - they are very much real and we are making
> good use of it.

I don't mind at all if rawhide users run on the latest and greatest, but
release users deserve a little more stability.

error compiling committee.c: too many arguments to function

 \ /
  Last update: 2010-03-18 14:49    [W:0.256 / U:9.036 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site