From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd0CX-0008V8-Om for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:57:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd0CR-0001j4-Uf for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:57:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd0CR-0001in-O3 for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:57:47 -0500 Message-ID: <4EF09453.3030505@redhat.com> Date: Tue, 20 Dec 2011 14:57:39 +0100 From: Paolo Bonzini 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> In-Reply-To: <4EF0937D.3090207@codemonkey.ws> 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: Anthony Liguori Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Avi Kivity 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. :) We sure can revisit this when the subclassing and interface infrastructures of QOM are merged. Paolo