Daniel P. Berrangé <berra...@redhat.com> writes:
> 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.
Me too.
>> 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)
Very nice to have.
In case teaching it to checkpatch turns out to be too onerous: perhaps
certain things would be easier to check in a program that looks at
sources rather than patches. Other projects have that as "make
syntax-check".
