Re: [Qemu-devel] Issues around TYPE_INTERFACE

[Daniel P . Berrangé]

On Mon, Mar 18, 2019 at 11:59:43AM +0000, Peter Maydell wrote:
> On Mon, 18 Mar 2019 at 11:54, Daniel P. Berrangé <address@hidden> wrote:
> > >     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
> >
> > I'm not so bothered by these, though they are pointless unless
> > perhaps it is to avoid clash with a similarly named object
> > type
> 
> For the ones of these that I'm responsible for, I was
> partly following an existing example, but I find it useful
> as a user of the APIs that it's clear that I'm dealing
> with an interface and not an object. For instance if I
> see a PROP_LINK that wants a TYPE_IDAU_INTERFACE I know
> I need to implement an interface on some suitable object,
> whereas if it were a TYPE_IDAU I'd be expecting to need
> to create (or write a subclass of) a concrete object.
> So I'd prefer us to settle on a convention that does
> explicitly mark the interface-ness in the type name.

If we do want such a naming convention, then I think we'd want to have
checkpatch enforce it. eg in the .c file validate the TypeInfo struct:

    static const TypeInfo acpi_dev_if_info = {
        .name          = TYPE_ACPI_DEVICE_IF,
        .parent        = TYPE_INTERFACE,
        .class_size = sizeof(AcpiDeviceIfClass),
    };

If '.parent'  is a TYPE_INTERFACE, or another type ending in _IF, then
enforce the .name also ends in _IF  (or whatever name convention we
pick)

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|