[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Issues around TYPE_INTERFACE
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [Qemu-devel] Issues around TYPE_INTERFACE |
Date: |
Thu, 28 Mar 2019 23:23:02 +0100 |
Le lun. 18 mars 2019 14:04, Markus Armbruster <address@hidden> a écrit :
> Daniel P. Berrangé <address@hidden> 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é <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.
>
> Me too.
>
+2
> >> 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)
>
What about abstract objects?
> 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".
>
make cocci-check?
>
- [Qemu-devel] Issues around TYPE_INTERFACE, Markus Armbruster, 2019/03/12
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Daniel P . Berrangé, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Peter Maydell, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Daniel P . Berrangé, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Markus Armbruster, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Daniel P . Berrangé, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Peter Maydell, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE, Daniel P . Berrangé, 2019/03/18
- Re: [Qemu-devel] Issues around TYPE_INTERFACE,
Philippe Mathieu-Daudé <=
Re: [Qemu-devel] Issues around TYPE_INTERFACE, Markus Armbruster, 2019/03/18
Re: [Qemu-devel] Issues around TYPE_INTERFACE, Markus Armbruster, 2019/03/28