From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754726Ab1KFTRw (ORCPT ); Sun, 6 Nov 2011 14:17:52 -0500 Received: from mail-vx0-f174.google.com ([209.85.220.174]:40147 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754412Ab1KFTRt convert rfc822-to-8bit (ORCPT ); Sun, 6 Nov 2011 14:17:49 -0500 MIME-Version: 1.0 In-Reply-To: <4EB6DBC6.2010404@redhat.com> References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB6DBC6.2010404@redhat.com> Date: Sun, 6 Nov 2011 21:17:48 +0200 X-Google-Sender-Auth: 1ZZNsTtKtYEjehzCnrKsG0HsnVM Message-ID: Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels From: Pekka Enberg To: Paolo Bonzini Cc: Alexander Graf , "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Blue Swirl , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini wrote: >> I really don't see the point in doing that. We want to be part of >> regular kernel history and release cycle. > > But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of > years, I want all the shining new features you added in this time; I don't > want the old end-2011 code.  Same if I'm bisecting kernels, I don't want to > build KVM tool once per bisection cycle, do I? If you're bisecting breakage that can be in the guest kernel or the KVM tool, you'd want to build both. What would prevent you from using a newer KVM tool with an older kernel? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN8E2-0003Xm-Bb for qemu-devel@nongnu.org; Sun, 06 Nov 2011 14:17:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RN8E1-0008Ot-Cl for qemu-devel@nongnu.org; Sun, 06 Nov 2011 14:17:50 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:43731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN8E1-0008Oj-9X for qemu-devel@nongnu.org; Sun, 06 Nov 2011 14:17:49 -0500 Received: by vws17 with SMTP id 17so3594418vws.4 for ; Sun, 06 Nov 2011 11:17:48 -0800 (PST) MIME-Version: 1.0 Sender: penberg@gmail.com In-Reply-To: <4EB6DBC6.2010404@redhat.com> References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> <877C82F4-F07C-44AA-8722-3AF57CFC4597@suse.de> <4EB6DBC6.2010404@redhat.com> Date: Sun, 6 Nov 2011 21:17:48 +0200 Message-ID: From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "kvm@vger.kernel.org list" , qemu-devel Developers , "linux-kernel@vger.kernel.org List" , Alexander Graf , Blue Swirl , Avi Kivity , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini wrote: >> I really don't see the point in doing that. We want to be part of >> regular kernel history and release cycle. > > But I'm pretty certain that, when testing 3.2 with KVM tool in a couple o= f > years, I want all the shining new features you added in this time; I don'= t > want the old end-2011 code. =A0Same if I'm bisecting kernels, I don't wan= t to > build KVM tool once per bisection cycle, do I? If you're bisecting breakage that can be in the guest kernel or the KVM tool, you'd want to build both. What would prevent you from using a newer KVM tool with an older kernel?