lkml.org 
[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project

* Avi Kivity <avi@redhat.com> wrote:

> On 03/18/2010 03:31 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@redhat.com> 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. [...]

I just replied to Frank Ch. Eigler with a specific example that shows how this
happens - and believe me, it happens.

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

Nope - RHEL 5 is on a 2.6.18 base for entirely different reasons.

> Kernel updates = reboots.

If you check the update frequency of RHEL 5 kernels you'll see that it's
comparable to that of Fedora.

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

Happy choice or not, this is what i said is the distro practice these days. (i
dont know all the distros that well so i'm sure there's differences)

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

Rawhide is generally for latest released versions, to ready them for the next
distro release - with special exception for the kernel, which has a special
position due being a hardware-enabler and because it has an extremely
predictable release schedule of every 90 days (+- 10 days).

Very rarely do distro people jump versions for things like GCC or Xorg or
Gnome/KDE, but they've been burned enough times by unexpected delays in those
projects to be really loathe to do it.

Qemu might get an exception - dunno, you could ask. My point still holds: by
hosting KVM user-space bits in the kernel together with the rest of KVM you
get version parity - which has clear advantages.

You also might have more luck with a bleeding-edge distro such as Gentoo.

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

What are you suggesting, that released versions of KVM are not reliable? Of
course any tools/ bits are release engineered just as much as the rest of KVM
...

Ingo


\
 
 \ /
  Last update: 2010-03-18 14:59    [from the cache]
©2003-2011 Jasper Spaans