Il 02/05/2012 00:18, Anthony Liguori ha scritto:
> anthony@titi:~/build/qemu$ x86_64-softmmu/qemu-system-x86_64 -device
> rtl8139,?
>
I don't think this is a fair comparison, or makes sense at all. The cause
of the bug in master is a cut-and-paste typo:
@@ -157,7 +157,7 @@ int qdev_device_help(
On 05/01/2012 05:18 PM, Andreas Färber wrote:
Am 01.05.2012 23:47, schrieb Paolo Bonzini:
I think it's too late for this series to go into 1.1.
In that case this is calling for a qom-next branch...
I really prefer to do this for 1.1. We've got a large enough testing window and
these patche
On 05/01/2012 04:47 PM, Paolo Bonzini wrote:
Il 01/05/2012 22:46, Anthony Liguori ha scritto:
So I think we can safely break it :-)
Does this work with compat properties set on a bus?
No :-(
This is pretty easy to fix though. The attached should do the trick,
I'll update and send out.
Am 01.05.2012 23:47, schrieb Paolo Bonzini:
> I think it's too late for this series to go into 1.1.
In that case this is calling for a qom-next branch...
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nü
Il 01/05/2012 22:46, Anthony Liguori ha scritto:
>>>
>>>
>>> So I think we can safely break it :-)
>>
>> Does this work with compat properties set on a bus?
>
> No :-(
>
> This is pretty easy to fix though. The attached should do the trick,
> I'll update and send out.
>
> Even if it does,
>>
On 05/01/2012 03:37 PM, Paolo Bonzini wrote:
Il 01/05/2012 20:18, Anthony Liguori ha scritto:
This is technically a compatibility breaker. However:
1) libvirt does not rely on this (it always uses the driver name)
2) This behavior isn't actually documented anywhere (the docs just say driver).
Il 01/05/2012 20:18, Anthony Liguori ha scritto:
> This is technically a compatibility breaker. However:
>
> 1) libvirt does not rely on this (it always uses the driver name)
>
> 2) This behavior isn't actually documented anywhere (the docs just say
> driver).
>
> 3) I suspect there are less t
This is technically a compatibility breaker. However:
1) libvirt does not rely on this (it always uses the driver name)
2) This behavior isn't actually documented anywhere (the docs just say driver).
3) I suspect there are less than three people on earth that even know this is
possible (minu
This is technically a compatibility breaker. However:
1) libvirt does not rely on this (it always uses the driver name)
2) This behavior isn't actually documented anywhere (the docs just say driver).
3) I suspect there are less than three people on earth that even know this is
possible (minu
