From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse Date: Tue, 20 Dec 2011 18:02:45 +0100 Message-ID: <4EF0BFB5.6060502@siemens.com> 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> <4EF096AC.4070803@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity To: Anthony Liguori Return-path: Received: from goliath.siemens.de ([192.35.17.28]:18517 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097Ab1LTRC6 (ORCPT ); Tue, 20 Dec 2011 12:02:58 -0500 In-Reply-To: <4EF096AC.4070803@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-12-20 15:07, Anthony Liguori wrote: > 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. Do we have a clear plan now how to sort out the addressing issues in this model? I mean when registering two devices under different names that are supposed to be addressable under the same alias once instantiated. I didn't follow recent qtree naming changes in details unfortunately, if they already enable this. This does not need to be implemented before merge. I just like to have a common view on how to address it once it matters (for device inspection). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux