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. Regards, Halil > > Signed-off-by: Eduardo Habkost <ehabk...@redhat.com>