From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd0MF-0004fG-5N for qemu-devel@nongnu.org; Tue, 20 Dec 2011 09:08:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd0M3-00049d-Um for qemu-devel@nongnu.org; Tue, 20 Dec 2011 09:07:54 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:44263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd0M3-00049V-Qu for qemu-devel@nongnu.org; Tue, 20 Dec 2011 09:07:43 -0500 Received: by yhgg71 with SMTP id g71so5436811yhg.4 for ; Tue, 20 Dec 2011 06:07:43 -0800 (PST) Message-ID: <4EF096AC.4070803@codemonkey.ws> Date: Tue, 20 Dec 2011 08:07:40 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EEFB72E.7030508@codemonkey.ws> <4EEFC970.9030205@web.de> <4EEFD69F.6080700@codemonkey.ws> <4EEFD786.8030609@web.de> <4EEFD90A.1000204@codemonkey.ws> <4EF05BC4.8010905@redhat.com> <4EF09078.2030508@codemonkey.ws> <4EF092D2.6080009@redhat.com> <4EF0937D.3090207@codemonkey.ws> <4EF09453.3030505@redhat.com> In-Reply-To: <4EF09453.3030505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Avi Kivity On 12/20/2011 07:57 AM, Paolo Bonzini wrote: > On 12/20/2011 02:54 PM, Anthony Liguori wrote: >>> In QOM parlance Jan implemented this: >>> >>> abstract class Object >>> abstract class Device >>> class APIC: { backend: link } >>> abstract class APICBackend >>> class QEMU_APICBackend >>> class KVM_APICBackend >> >> I don't fundamentally object to modeling it like this provided that it's >> modeled (and visible) through qdev and not done through a one-off >> infrastructure. > > There is no superclass of DeviceState, hence doing it through qdev would mean > introducing a new bus type and so on. This would be a superb example of a > useless bus that can disappear with QOM, but I don't see why we should take the > pain to add it in the first place. :) Right, so let's modeled it for now as inheritance which qdev can cope with. > > We sure can revisit this when the subclassing and interface infrastructures of > QOM are merged. I'll have patches out this week (just trying to write some more test cases). The latest series is below if you're interested. I fear that it won't be until mid to late January before this can be merged though as I want to give folks like Markus a chance to review it. https://github.com/aliguori/qemu/tree/qom-upstream.3 Regards, Anthony Liguori > > Paolo >