From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47365 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnUE3-0003pe-18 for qemu-devel@nongnu.org; Mon, 23 Aug 2010 06:26:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnUDz-000519-2x for qemu-devel@nongnu.org; Mon, 23 Aug 2010 06:25:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23596) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnUDy-00050z-SH for qemu-devel@nongnu.org; Mon, 23 Aug 2010 06:25:55 -0400 Message-ID: <4C724CA8.5080102@redhat.com> Date: Mon, 23 Aug 2010 13:25:44 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 0/7] APIC/IOAPIC cleanup References: <4C6D86F9.3010602@codemonkey.ws> <4C6D98E7.9020109@codemonkey.ws> <4C70EFC9.2050404@redhat.com> <4C7171EB.7090301@codemonkey.ws> <4C717E05.50609@redhat.com> <4C718296.8030405@codemonkey.ws> <4C71898E.9090105@redhat.com> <4C71913C.5090300@codemonkey.ws> <4C720BF1.6090305@redhat.com> <4C723ABE.4080801@siemens.com> <4C723E78.4090603@redhat.com> <4C724A5D.1030301@redhat.com> <74BFF8A5-7CB6-40F8-A9D0-5E5E6368C5EE@suse.de> In-Reply-To: <74BFF8A5-7CB6-40F8-A9D0-5E5E6368C5EE@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Blue Swirl , Jan Kiszka , Jinsong Liu , qemu-devel , Paul Brook On 08/23/2010 01:18 PM, Alexander Graf wrote: > >> I certainly don't, but others may. >> >> However, the problem remains: every time real hardware doesn't fit our pretty model we'll drop support for that hardware? > No, every time real hardware doesn't fit out pretty model and nobody really cares, we don't care. > > Seriously - would you want to start off modeling everything so that EISA and MCA fit in too? Look how this developed: 1. apic.c has an incestuous relationship with the cpu 2. let's make them one and the same 3. but in real life they're not one and the same in some cases 4. including some we support 5. let's drop support for those vs 1. hardware isn't a tree 2. we have to live with that Dropping support for 486 is fine, but let's not do it because we want to model hardware in a way that's different from reality -- error compiling committee.c: too many arguments to function