qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Issues around TYPE_INTERFACE


From: Markus Armbruster
Subject: [Qemu-devel] Issues around TYPE_INTERFACE
Date: Tue, 12 Mar 2019 11:50:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

We have two separate type trees, object types rooted at TYPE_OBJECT, and
interface types at TYPE_INTERFACE.

Object types are fore defining ultimately concrete types, i.e. any
concrete type is a descendant of TYPE_OBJECT.  Interior nodes of the
TYPE_OBJECT tree are commonly abstract, with a few exceptions.  Leaves
need to be concrete to be of any use.

Interface types are for defining interfaces object types provide (by
listing them in a type's .interfaces).  TYPE_INTERFACE and all its
descendants are abstract.

Issue #1: INTERFACE_CLASS()

    #define OBJECT_CLASS(class) \
        ((ObjectClass *)(class))

    #define OBJECT_CLASS_CHECK(class_type, class, name) \
        ((class_type *)object_class_dynamic_cast_assert(OBJECT_CLASS(class), 
(name), \
                                                   __FILE__, __LINE__, 
__func__))

    #define INTERFACE_CLASS(klass) \
        OBJECT_CLASS_CHECK(InterfaceClass, klass, TYPE_INTERFACE)

Shouldn't INTERFACE_CLASS() be named INTERFACE_CLASS_CHECK() for
consistency?

Rename would be trivial, as there are no uses.

Issue #2: INTERFACE_CHECK()

    #define OBJECT_CHECK(type, obj, name) \
        ((type *)object_dynamic_cast_assert(OBJECT(obj), (name), \
                                            __FILE__, __LINE__, __func__))

    #define INTERFACE_CHECK(interface, obj, name) \
        ((interface *)object_dynamic_cast_assert(OBJECT((obj)), (name), \
                                                 __FILE__, __LINE__, __func__))

The two are identical (except the former lacks parenthesis around obj,
which is a minor bug).

Obvious question: shouldn't we de-duplicate the code?

There's a more interesting question, however.  Since two two are
identical, they can be used interchangeably.  And since we can, we do;
for instance

    #define QAUTHZ(obj) \
         INTERFACE_CHECK(QAuthZ, (obj), \
                         TYPE_QAUTHZ)

even though TYPE_QAUTHZ is a sub-type of TYPE_OBJECT, not
TYPE_INTERFACE.  Shouldn't we prevent that somehow?  Or maybe embrace
they're the same and just get rid of INTERFACE_CHECK() entirely?

Issue #3: Inconsistent naming (surprise, surprise)

The confusion between object and interface types is of course aggravated
by our usual lack of discipline in naming.  I recognize no less than
three naming conventions:

    INTERFACE_CONVENTIONAL_PCI_DEVICE
    INTERFACE_PCIE_DEVICE

    TYPE_ACPI_DEVICE_IF
    TYPE_ARM_LINUX_BOOT_IF
    TYPE_TEST_IF
    TYPE_TPM_IF

    TYPE_IDAU_INTERFACE
    TYPE_IPMI_INTERFACE
    TYPE_PNV_XSCOM_INTERFACE

Yet they're used for less than half of the interface names:

    TYPE_FW_PATH_PROVIDER
    TYPE_HOTPLUG_HANDLER
    TYPE_INTERRUPT_STATS_PROVIDER
    TYPE_ISADMA
    TYPE_MEMORY_DEVICE
    TYPE_NMI
    TYPE_NVRAM
    TYPE_PPC_VIRTUAL_HYPERVISOR
    TYPE_STREAM_SLAVE
    TYPE_USER_CREATABLE
    TYPE_XICS_FABRIC
    TYPE_XIVE_NOTIFIER

Can we agree on one naming convention, and enforce it?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]