From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754394Ab0CROwi (ORCPT ); Thu, 18 Mar 2010 10:52:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63482 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754352Ab0CROwg (ORCPT ); Thu, 18 Mar 2010 10:52:36 -0400 Message-ID: <4BA23E09.2050701@redhat.com> Date: Thu, 18 Mar 2010 16:51:53 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: Ingo Molnar CC: "Frank Ch. Eigler" , Alexander Graf , Anthony Liguori , "Zhang, Yanmin" , Peter Zijlstra , Sheng Yang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Marcelo Tosatti , oerg Roedel , Jes Sorensen , Gleb Natapov , Zachary Amsden , ziteng.huang@intel.com, Arnaldo Carvalho de Melo , Fr?d?ric Weisbecker Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single project References: <20100318101025.GA13073@elte.hu> <4BA1FEB0.7000400@redhat.com> <20100318113527.GA13168@elte.hu> <20100318130226.GB7424@elte.hu> <4BA22663.7070509@redhat.com> <20100318133124.GA25642@elte.hu> <4BA22E9E.4000607@redhat.com> <20100318135700.GC25642@elte.hu> <4BA237E2.10303@redhat.com> <20100318143656.GA20182@elte.hu> In-Reply-To: <20100318143656.GA20182@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/18/2010 04:36 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >>> 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) >>> >> So in addition to all the normal kernel regressions, you want to force >> tools/kvm/ regressions on users. >> > So instead you force a NxN compatibility matrix [all versions of qemu combined > with all versions of the kernel] instead of a linear N versions matrix with a > clear focus on the last version. Brilliant engineering i have to say ;-) > Thanks. In fact with have an QxKxGxT compatibility matrix since we need to keep compatibility with guests and with tools. Since the easiest interface to keep compatible is the qemu/kernel interface, allowing the kernel and qemu to change independently allows reducing the compatibility matrix while still providing some improvements. Regardless of that I'd keep binary compatibility anyway. Not everyone is on the update treadmill with everything updating every three months and those people appreciate stability. I intend to keep providing it. > Also, by your argument the kernel should be split up into a micro-kernel, with > different packages for KVM, scheduler, drivers, upgradeable separately. > Some kernels do provide some of that facility (without being microkernels), for example the Windows and RHEL kernels. So it seems people want it. > That would be a nightmare. (i can detail many facets of that nightmare if you > insist but i'll spare the electrons for now) Fortunately few kernel developers > share your views about this. > I'm not sure you know my views about this. >>>> 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 ... >>> >> No, I am suggesting qemu-kvm.git is not as stable as released versions (and >> won't get fixed backported). Keep in mind that unlike many userspace >> applications, qemu exposes an ABI to guests which we must keep compatible. >> > I think you still dont understand it: if a tool moves to the kernel repo, then > it is _released stable_ together with the next stable kernel. > I was confused by the talk about 2.6.34-rc1, which isn't stable. -- error compiling committee.c: too many arguments to function