From mboxrd@z Thu Jan 1 00:00:00 1970 From: john cooper Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Date: Thu, 21 Jan 2010 11:43:52 -0500 Message-ID: <4B588448.7090303@redhat.com> References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119200349.GG3204@sequoia.sous-sol.org> <4B563144.9030803@codemonkey.ws> <4B576311.3030906@redhat.com> <20100120202634.GA20754@redhat.com> <20100121002509.GM3204@sequoia.sous-sol.org> <4B57AB66.30802@redhat.com> <4B586D4A.50207@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Chris Wright , "Daniel P. Berrange" , "Przywara, Andre" , qemu-devel@nongnu.org, KVM list , Gerd Hoffmann , john.cooper@redhat.com To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53440 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751856Ab0AUQsl (ORCPT ); Thu, 21 Jan 2010 11:48:41 -0500 In-Reply-To: <4B586D4A.50207@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > On 01/20/2010 07:18 PM, john cooper wrote: >> I can appreciate the concern of wanting to get this >> as "correct" as possible. >> > > This is the root of the trouble. At the qemu layer, we try to focus on > being correct. > > Management tools are typically the layer that deals with being "correct". > > A good compromise is making things user tunable which means that a > downstream can make "correctness" decisions without forcing those > decisions on upstream. Conceptually I agree with such a malleable approach -- actually I prefer it. I thought however it was too much infrastructure to foist on the problem just to add a few more models into the mix. The only reservation which comes to mind is that of logistics. This may ruffle the code some and impact others such as Andre who seem to have existing patches relative to the current structure. Anyone have strong objections to this approach before I have a look at an implementation? Thanks, -john -- john.cooper@redhat.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NY0D0-0004Pd-NY for qemu-devel@nongnu.org; Thu, 21 Jan 2010 11:48:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NY0Cv-0004OC-Uf for qemu-devel@nongnu.org; Thu, 21 Jan 2010 11:48:38 -0500 Received: from [199.232.76.173] (port=39191 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NY0Cv-0004O9-Mb for qemu-devel@nongnu.org; Thu, 21 Jan 2010 11:48:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57811) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NY0Cu-0008Fu-8W for qemu-devel@nongnu.org; Thu, 21 Jan 2010 11:48:33 -0500 Message-ID: <4B588448.7090303@redhat.com> Date: Thu, 21 Jan 2010 11:43:52 -0500 From: john cooper MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119200349.GG3204@sequoia.sous-sol.org> <4B563144.9030803@codemonkey.ws> <4B576311.3030906@redhat.com> <20100120202634.GA20754@redhat.com> <20100121002509.GM3204@sequoia.sous-sol.org> <4B57AB66.30802@redhat.com> <4B586D4A.50207@codemonkey.ws> In-Reply-To: <4B586D4A.50207@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Przywara, Andre" , KVM list , john.cooper@redhat.com, qemu-devel@nongnu.org, Chris Wright , Gerd Hoffmann Anthony Liguori wrote: > On 01/20/2010 07:18 PM, john cooper wrote: >> I can appreciate the concern of wanting to get this >> as "correct" as possible. >> > > This is the root of the trouble. At the qemu layer, we try to focus on > being correct. > > Management tools are typically the layer that deals with being "correct". > > A good compromise is making things user tunable which means that a > downstream can make "correctness" decisions without forcing those > decisions on upstream. Conceptually I agree with such a malleable approach -- actually I prefer it. I thought however it was too much infrastructure to foist on the problem just to add a few more models into the mix. The only reservation which comes to mind is that of logistics. This may ruffle the code some and impact others such as Andre who seem to have existing patches relative to the current structure. Anyone have strong objections to this approach before I have a look at an implementation? Thanks, -john -- john.cooper@redhat.com