From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3PVG-0004Sl-7b for qemu-devel@nongnu.org; Sun, 28 Jul 2013 07:51:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3PVA-0001ol-9X for qemu-devel@nongnu.org; Sun, 28 Jul 2013 07:51:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59159 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3PVA-0001og-0L for qemu-devel@nongnu.org; Sun, 28 Jul 2013 07:51:04 -0400 Message-ID: <51F505A2.6010403@suse.de> Date: Sun, 28 Jul 2013 13:50:58 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1374532568-28051-1-git-send-email-afaerber@suse.de> In-Reply-To: <1374532568-28051-1-git-send-email-afaerber@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH qom-next v2 0/4] QOM'ification of pci-bridge types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Peter Crosthwaite , Hu Tao , qemu-devel@nongnu.org, Don Koch , Anthony Liguori , Paolo Bonzini Am 23.07.2013 00:36, schrieb Andreas F=C3=A4rber: > Andreas F=C3=A4rber (4): > pci-bridge: Turn PCIBridge into abstract QOM type > pci-bridge-dev: QOM parent field cleanup > pci-bridge/i82801b11: Rename parent field > pcie_port: Turn PCIEPort and PCIESlot into abstract QOM types Thanks, applied to qom-next: https://github.com/afaerber/qemu-cpu/commits/qom-next The story behind parent_obj and the gtk-doc markup as far as I've inferred from Anthony's patches is a) C++ for one does not have a field to access the parent class' fields, you access them directly, which TYPE_NAME() casts and using different-but-the-same pointers abstract and b) it makes it easier for me to recognize which struct corresponds to a QOM object and which is just used inside some object's struct or elsewher= e. The practical use of renaming for me is to have the compiler check for parent field uses, to avoid concurrent merges such as Don's PCIBridge fix (which should go through the appropriate queues without delay, no criticism there) adding more uses and a 98% cleanup getting merged afterwards, requiring yet another round of cleanups. (Compare my SysBus cleanups, where I missed some ->qdev accesses, which I only noticed later when I did rename the parent field.) I've sent out a series cleaning up the aer_log VMSTATE_STRUCT() and VMSTATE_MSIX() for you and Juan to review, which minimizes the use of parent_obj chains. That leaves VMSTATE_PCIE_DEVICE() as user of parent_obj; I'm not sure about how to interpret Anthony's comment on v1, I'll inquire and hope we can get this cleaned up post-1.6, too. Ideally before more PCI parent fields get renamed and show up in such diffs. One cool out-of-tree use case for PCI_DEVICE() that Peter C. has been explaining to me is reuse of PCI IP with SysBus by changing the .parent of TYPE_PCI_DEVICE and replacing the qdev field accordingly. Not applicable to upstream of course, we'd need QOM interfaces for that and I guess, a VMState solution for such "multi-inheritence" interfaces. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg