Re: [Qemu-devel] [PATCH qom-next v2 0/4] QOM'ification of pci-bridge types

["Andreas Färber" <afaerber@suse.de>]

Am 23.07.2013 00:36, schrieb Andreas Färber:
> Andreas Färber (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 elsewhere.

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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg