From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrbro-0003CK-Sc for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:47:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrbrj-0003B3-Ep for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:47:15 -0400 Received: from [199.232.76.173] (port=47612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrbrj-0003Ax-8y for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:47:11 -0400 Received: from mx20.gnu.org ([199.232.41.8]:16314) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lrbri-0003Gx-UX for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:47:11 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lrbrh-0007kI-Tw for qemu-devel@nongnu.org; Wed, 08 Apr 2009 13:47:10 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: start qemu failed with --enable-kvm -vga std Date: Wed, 8 Apr 2009 17:47:06 +0000 References: <5d6222a80904081006w65228ac7k3b6e759e08f4c8b3@mail.gmail.com> <5d6222a80904081025j1644b6bay17d1ff942247971@mail.gmail.com> <20090408.113954.-1962672847.imp@bsdimp.com> In-Reply-To: <20090408.113954.-1962672847.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904081847.07083.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: glommer@gmail.com, glommer@redhat.com On Wednesday 08 April 2009, M. Warner Losh wrote: > In message: <5d6222a80904081025j1644b6bay17d1ff942247971@mail.gmail.com> > > Glauber Costa writes: > : In all seriousness, no matter how good your series for improving kvm > : registration > : are, it is unlikely to hit the stable branch. So I believe a good deal > : would have something > : on the line of this patch applied to stable, leaving unstable as is, > : until we can find a better > : solution. > > Huh? It is unlikely to be merged into stable, so let's commit it to > stable? I think the suggestion is that we apply an ugly hack on just the stable branch, and fix it properly later on the development. FWIW I think this is a bad idea. We should never fix something on the stable branch that isn't also fixed on the development branch. If the changes are causing problems, then my suggestion is to revert the original change (i.e. the support for >64k roms). Paul