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
