PCI addresses are set with qdev_prop_uint32. Thus we make the QOM
property accept a device and function encoded in an 8-bit integer,
instead of the magic dd.f hex string.
Signed-off-by: Paolo Bonzini
---
hw/qdev-properties.c | 25 +++--
1 files changed, 7 insertions(+), 18
On 02/02/2012 10:45 AM, Paolo Bonzini wrote:
PCI addresses are set with qdev_prop_uint32. Thus we make the QOM
property accept a device and function encoded in an 8-bit integer,
instead of the magic dd.f hex string.
Signed-off-by: Paolo Bonzini
Isn't this a compatibility breaker?
Won't this
On 02/02/2012 09:07 PM, Anthony Liguori wrote:
Signed-off-by: Paolo Bonzini
Isn't this a compatibility breaker?
Won't this break libvirt's usage of -device addr=0.2 ?
Nope, the legacy property still keeps the dd.f format. This is only for
QOM (and internal use by qdev).
Paolo
On 02/02/2012 02:19 PM, Paolo Bonzini wrote:
On 02/02/2012 09:07 PM, Anthony Liguori wrote:
Signed-off-by: Paolo Bonzini
Isn't this a compatibility breaker?
Won't this break libvirt's usage of -device addr=0.2 ?
Nope, the legacy property still keeps the dd.f format. This is only for QOM (a
On 02/03/2012 03:14 PM, Anthony Liguori wrote:
Nope, the legacy property still keeps the dd.f format. This is only
for QOM (and
internal use by qdev).
Ah, I forgot we duplicate the properties here.
Since there is now a programmatic mapping between legacy properties
types and non-legacy prop
On 02/04/2012 01:21 AM, Paolo Bonzini wrote:
I'm not sure... we would trade removal of an ugly concept (the legacy
properties) with addition of a layering violation (poking into the
DeviceState subclasses).
The main problem here is that you said no to a hierarchy of property
classes. This is
On 02/03/2012 06:43 PM, Paolo Bonzini wrote:
On 02/04/2012 01:21 AM, Paolo Bonzini wrote:
I'm not sure... we would trade removal of an ugly concept (the legacy
properties) with addition of a layering violation (poking into the
DeviceState subclasses).
The main problem here is that you said no
On 02/04/2012 04:00 AM, Anthony Liguori wrote:
Yeah, I was just thinking out loud. My plan is to pull your series into
my qom-rebase branch.
The last few commits on
https://github.com/aliguori/qemu/tree/qom-rebase.12 have a variant
visitor and accessors that use it.
Ok, I'll cherry-pick fr
On 02/04/2012 07:42 AM, Paolo Bonzini wrote:
Ok, I'll cherry-pick from there and send out an updated patch series
later today.
... that won't work unfortunately. Enums are broken (not your fault
really, I sent this before losttickpolicy went in); I really dislike
having a single object that
