From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56375 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnHm4-0006at-4i for qemu-devel@nongnu.org; Sun, 22 Aug 2010 17:08:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnHlh-0004QN-Ca for qemu-devel@nongnu.org; Sun, 22 Aug 2010 17:07:54 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:58700) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnHlh-0004QH-8V for qemu-devel@nongnu.org; Sun, 22 Aug 2010 17:07:53 -0400 Received: by yxn35 with SMTP id 35so2049923yxn.4 for ; Sun, 22 Aug 2010 14:07:52 -0700 (PDT) Message-ID: <4C7191A7.8030700@codemonkey.ws> Date: Sun, 22 Aug 2010 16:07:51 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [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> In-Reply-To: <4C717E05.50609@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , "Liu >> \"Liu, Jinsong\"" , qemu-devel , Paul Brook On 08/22/2010 02:44 PM, Avi Kivity wrote: >> No more MI diamond and all devices have DeviceStates. >> Coincidentally, it matches more closely how hardware works.. >> > > > Well, I agree, but I honestly lost the context. How does this relate > to the APIC and cpu hotplug? > > I'll take the opportunity to say that we should be using a language > that has first-class (...) support for these concepts instead of > having to divine them from the code. At the risk of sounding uncool, I think what we really need is a UML diagram describing the device tree. It's really not that much more difficult to create a similar mess in C++. Regards, Anthony Liguori >> Generally speaking, any time we have one device that needs to sit on >> multiple busses, we're going to have to model it in this fashion. > > We'll just have to address them one by one then. Perhaps if many come > up we can try a generic solution. >