Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

[Markus Armbruster]

"Daniel P. Berrange" <address@hidden> writes:

> On Mon, Nov 07, 2016 at 03:48:49PM +0100, Halil Pasic wrote:
>> 
>> 
>> On 11/07/2016 02:05 PM, Eduardo Habkost wrote:
>> > If you want some subclasses to not have the property, then I
>> > recommend not registering it as a class property on the base
>> > class in the first place. I don't expect to see a mechanism to
>> > allow subclasses to remove or override class properties from
>> > parent classes.
>> > 
>> 
>> Thank you very much for your reply.
>> 
>> I understand, yet I see potential problems. The example with ioeventfd
>> and vhost in virtio-pci is a good one also because  the first there was
>> the ioeventfd property with commit 653ced07 and then the vhost case came
>> along with commit 50787628ee3 (ok ioeventfd is not there for some non
>> vhost virtio-pci devices for reasons I do not understand).
>> 
>> To rephrase this in generic context a specialization for which a
>> property does not make sense might come along after the property at the
>> base class was established.
>> 
>> Now AFAIU properties are external API, so having to make a compatibility
>> breaking change there might not be fun. Does this mean one should be
>> very careful to put only use class level properties on abstract classes
>> where its certain that the property always makes sense including it's
>> access control?
>
> This could be an argument for *NOT* allowing introspectiing of properties
> against abstract parent classes. If you only ever allow introspecting against
> leaf node non-abstract classes, then QEMU retains the freedom to move props
> from a base class down to an leaf class without risk of breaking mgmt apps.

That's a really good point.  To generalize it a bit, introspection of
actual interfaces is fine, but permitting introspection of how they are
made can add artificial constraints.

Introspecting the subtype relation is already problematic in this view.