Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Avi Kivity <avi@redhat.com>]

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