On Mon, Mar 18, 2019 at 11:59:43AM +0000, Peter Maydell wrote:
> On Mon, 18 Mar 2019 at 11:54, Daniel P. Berrangé <berra...@redhat.com> 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 :|
