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

[Eduardo Habkost]

On Mon, Nov 07, 2016 at 01:45:59PM +0100, Halil Pasic wrote:
> 
> 
> On 10/29/2016 03:48 AM, Eduardo Habkost wrote:
> > When an abstract class is used on device-list-properties, we can
> > simply return the class properties registered for the class.
> > 
> > This will be useful if management software needs to query for
> > supported options that apply to all devices of a given type (e.g.
> > options supported by all CPU models, options supported by all PCI
> > devices).
> 
> This will question is slightly off topic (sorry about that) but it does
> concern the feature you are trying to establish. 
> 
> I stumbled upon this while trying clean up qdev properties in
> virtio-ccw. What I dislike is that there is a bunch of properties which
> are conceptually inherited from ancestor classes (like devno from
> CcwDevice) yet the qdev properties are independent at the moment (that
> is each device declares the devno property for itself -- lots of code
> duplication).
> 
> Now here comes the problem. The ioeventfd property is a property of the
> transport (that is logically belonging to VirtioCcwDevice) and tells if
> QEMU should use ioeventfd for notifiers. The trouble is this property is
> not present for vhost devices since basically the ioeventfd is used by
> the in host kernel vhost driver, so the degree of freedom is gone. By
> the way, we have the same with virtio-pci and there the ioeventfd
> property was simply left out of common virtio-pci properties regardless
> of the properties memory backing (where the set writes to and get reads
> from) sitting in that is the base class.
> 
> Now I think loosing a degree of freedom in the process of specialization
> is not something outrageous, but I was unable to figure out how this is
> to be modeled with your class based property approach. Can you help me
> here?
> 
> With the old object anchored properties I was tempted to do something
> like simply just removing the property form the object or overriding it
> with a read only property but this would now break the semantic of
> class properties. Of course having the data backing in the parent and
> the property in the child does work but is IMHO kind of ugly.

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.

You have many alternatives in this case: you could use instance
properties, or register it as class property only on some
subclasses (class_base_init could you help you do it on a single
place, instead of duplicating the property registration code on
subclasses).

-- 
Eduardo