Message-ID: <4BA22E9E.4000607@redhat.com>
Date:	Thu, 18 Mar 2010 15:46:06 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"Frank Ch. Eigler" <fche@...hat.com>,
	Alexander Graf <agraf@...e.de>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [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<avi@...hat.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.  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists