[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.023 / U:13.524 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site