qemu-devel
[Top][All Lists]
Advanced

[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: Halil Pasic
Subject: Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Date: Mon, 7 Nov 2016 13:45:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


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 <address@hidden>




reply via email to

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