From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmhLs-0000lD-US for qemu-devel@nongnu.org; Fri, 29 Jul 2011 03:19:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmhLr-0007Bd-F2 for qemu-devel@nongnu.org; Fri, 29 Jul 2011 03:19:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmhLr-0007BF-7i for qemu-devel@nongnu.org; Fri, 29 Jul 2011 03:19:19 -0400 Message-ID: <4E325EF1.2090007@redhat.com> Date: Fri, 29 Jul 2011 09:19:13 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1311558293-5855-1-git-send-email-aliguori@us.ibm.com> <4E2EBA1E.90006@redhat.com> <4E2EC90E.8090409@codemonkey.ws> <4E2ED0AA.3020101@redhat.com> <4E2EDE86.7020807@codemonkey.ws> <4E2F06C8.30403@redhat.com> <4E2F1448.3040106@codemonkey.ws> <4E2FD28F.2070206@redhat.com> <4E30091C.3070404@codemonkey.ws> <4E302FBF.4040500@redhat.com> <4E303CBF.8070801@codemonkey.ws> <4E305E3F.2050405@redhat.com> <4E306EA5.5020207@codemonkey.ws> <4E311160.8060506@redhat.com> <4E315A3F.90804@codemonkey.ws> <4E316924.8020001@redhat.com> <4E316C36.1050405@codemonkey.ws> <4E317514.30505@redhat.com> <4E317A96.7000604@codemonkey.ws> <4E318482.9030806@redhat.com> <4E31A374.7020705@codemonkey.ws> In-Reply-To: <4E31A374.7020705@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , qemu-devel@nongnu.org On 07/28/2011 07:59 PM, Anthony Liguori wrote: > Just define an interface that returns a struct then. It's no more > complicated than that. Ok, so we're debating whether to: 1) add an interface returning a pointer to an internal struct; 2) include in the internal struct a pointer-to-function that does a container_of and returns the outer Device object. Otherwise, we're on the same page. I'm quite relieved. ;) I can see advantages to both approach. The main advantage to (2) is that it scales better when you have multiple interfaces of the same kind exposed by the device. You cannot implement an interface twice. Paolo