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