From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1.0] ac97: don't override the pci subsystem id Date: Mon, 07 Nov 2011 17:00:21 +0200 Message-ID: <4EB7F285.9080009@redhat.com> References: <1320663634-29453-1-git-send-email-kraxel@redhat.com> <4EB7E896.9010108@redhat.com> <4EB7EC4A.90607@redhat.com> <4EB7EE62.7070805@redhat.com> <4EB7EEDD.4090604@codemonkey.ws> <4EB7F027.10209@redhat.com> <4EB7F0D8.2060306@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Takashi Iwai , Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Anthony Liguori Return-path: In-Reply-To: <4EB7F0D8.2060306@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 11/07/2011 04:53 PM, Anthony Liguori wrote: >> I think so, but that's unrelated. The worry is that some DRM code >> checksums your hardware and complains if it changed too much. Nothing >> to do with the test suite. >> >> The sense of Gerd's comment is reversed. We should preserve the ABI >> unless there is a strong reason not to. > > > Yes, I understand where you're coming from and I agree except when it > comes to bug fixes. > > My view toward bug fixes is the opposite--unless we know that the bug > fix breaks something, we should fix the bug. If it's a bug, we have to > assume it's breaking something. You're right in that not every bug fix deserves an entry in our quirk table. We don't want -M pc-0.15 to reintroduce a data corrupting bug just because it is guest visible! This is more of an edge case however, since we know that hardware tools rely on PCI IDs. For example our hypothetical ABI signature tool will certainly include lspci like functionality and detect this as a change. I now agree with both sides of the argument and can continue the discussion unaided for at least 30-40 emails. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNQgf-0008NY-Kn for qemu-devel@nongnu.org; Mon, 07 Nov 2011 10:00:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNQgU-00026d-OQ for qemu-devel@nongnu.org; Mon, 07 Nov 2011 10:00:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNQgU-00026F-F4 for qemu-devel@nongnu.org; Mon, 07 Nov 2011 10:00:26 -0500 Message-ID: <4EB7F285.9080009@redhat.com> Date: Mon, 07 Nov 2011 17:00:21 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1320663634-29453-1-git-send-email-kraxel@redhat.com> <4EB7E896.9010108@redhat.com> <4EB7EC4A.90607@redhat.com> <4EB7EE62.7070805@redhat.com> <4EB7EEDD.4090604@codemonkey.ws> <4EB7F027.10209@redhat.com> <4EB7F0D8.2060306@codemonkey.ws> In-Reply-To: <4EB7F0D8.2060306@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1.0] ac97: don't override the pci subsystem id List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Takashi Iwai , Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org On 11/07/2011 04:53 PM, Anthony Liguori wrote: >> I think so, but that's unrelated. The worry is that some DRM code >> checksums your hardware and complains if it changed too much. Nothing >> to do with the test suite. >> >> The sense of Gerd's comment is reversed. We should preserve the ABI >> unless there is a strong reason not to. > > > Yes, I understand where you're coming from and I agree except when it > comes to bug fixes. > > My view toward bug fixes is the opposite--unless we know that the bug > fix breaks something, we should fix the bug. If it's a bug, we have to > assume it's breaking something. You're right in that not every bug fix deserves an entry in our quirk table. We don't want -M pc-0.15 to reintroduce a data corrupting bug just because it is guest visible! This is more of an edge case however, since we know that hardware tools rely on PCI IDs. For example our hypothetical ABI signature tool will certainly include lspci like functionality and detect this as a change. I now agree with both sides of the argument and can continue the discussion unaided for at least 30-40 emails. -- error compiling committee.c: too many arguments to function