[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Date: Mon, 07 Nov 2016 16:51:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]