From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd018-0004N9-6r for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:46:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rd013-0007a5-U8 for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:46:06 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:36930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rd013-0007Zu-PK for qemu-devel@nongnu.org; Tue, 20 Dec 2011 08:46:01 -0500 Received: by yenm6 with SMTP id m6so4704753yen.4 for ; Tue, 20 Dec 2011 05:46:01 -0800 (PST) Message-ID: <4EF09196.5020502@codemonkey.ws> Date: Tue, 20 Dec 2011 07:45:58 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111219211737.GA17469@amt.cnet> <4EEFB9AE.7050309@codemonkey.ws> <4EEFCD71.5040603@web.de> <4EEFD7A9.3050007@codemonkey.ws> <4EEFD8D1.3060707@web.de> <4EEFDFFE.6000402@codemonkey.ws> <4EEFE2BD.2090201@web.de> <4EEFF708.3010104@codemonkey.ws> <4EF05D76.5070704@redhat.com> <4EF05E94.1090007@redhat.com> In-Reply-To: <4EF05E94.1090007@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/16] uq/master: Introduce basic irqchip support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Lai Jiangshan , kvm@vger.kernel.org, "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka On 12/20/2011 04:08 AM, Avi Kivity wrote: > On 12/20/2011 12:03 PM, Avi Kivity wrote: >> On 12/20/2011 04:46 AM, Anthony Liguori wrote: >>> >>> I would hope that you would agree that when designing the device >>> model, we should aim to do what makes sense independent of migration. >>> If we cannot achieve a certain feature with migration given the >>> logical modeling of devices, it probably suggests that we need to >>> improve our migration infrastructure. >>> >>> I assume that given the above, we all agree that separate devices is >>> what makes the most sense ignoring migration. >> >> I don't agree with this. > > The problem with having two devices, is that now you have to identify > the common code, put them somewhere, and use them as necessary. > > "apic" and "kvm-apic" both is-a (are-a?) "apic". This suggests either a > base class (containing the common code) and derived classes, or (like > Jan's implementation), just one class, that defers part of the > implementation to an interface implemented by two other classes. Yes, a base-class is what I'm suggesting since this is what qdev is capable of today. The other approach to this is to have an APICFrontend has-a APICBackend and then UserspaceAPIC is-a APICBackend and KernelAPIC is-a APICBackend. You still now have three visible devices in the device model. This is essentially what Jan's patches do today. I think a simple base-class + subclass inheritance scheme makes the most sense here. Regards, Anthony Liguori > > Two unrelated classes which happen to implement exactly the same > interface (vmstate fields) except one (visible name) and share some code > are a strange solution to this problem. >