[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

    * Avi Kivity <> wrote:

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

    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


     \ /
      Last update: 2010-03-18 14:59    [W:0.026 / U:5.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site