qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/16] qdev: fix hot-unplug


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 01/16] qdev: fix hot-unplug
Date: Thu, 2 Feb 2012 21:31:06 +0100

On 02.02.2012, at 21:03, Anthony Liguori wrote:

> On 02/02/2012 01:07 PM, Alexander Graf wrote:
>> 
>> On 02.02.2012, at 20:01, Anthony Liguori wrote:
>> 
>>> On 02/02/2012 11:29 AM, Paolo Bonzini wrote:
>>>> On 02/02/2012 06:03 PM, Anthony Liguori wrote:
>>>>>> 
>>>>> 
>>>>> Is this still needed with qom-upstream.14? I fixed a bug on .14 that
>>>>> involved child properties that was making device-del sometimes fail.
>>>> 
>>>> Not sure, I tried with .13 but, from the look of it, it should still be 
>>>> there.
>>>> Regarding the .13->.14 diff:
>>>> 
>>>> - you need QTAILQ_FOREACH_SAFE in object_property_del_child.
>>> 
>>> Ack.
>>> 
>>>> 
>>>> - you need to check for the existence of the non-aliased name when 
>>>> accessing the
>>>> alias table, because s390 does not have PCI.
>>> 
>>> I don't think that's the right strategy as it means that s390 only works if 
>>> we don't include the PCI objects in the build (regardless of whether it 
>>> uses PCI).  This would be defeated if/when we move to having all device 
>>> objects in a single shared library used by all of the qemu executables.
>>> 
>>> I'd prefer to just drop the aliases for s390.  I don't see a lot of value 
>>> in it and I don't think there are tons of s390 users that will be affected.
>> 
>> The reason for the aliases is to make -drive and -net work. If you have 
>> alternatives to aliases there, I'm happy to go with them.
> 
> We can simply do a const char *target_get_virtio_net_type(void) in 
> arch_init.c.
> 
> Not pretty, but we can later fix the -drive/-net calls to not require this.

Anything that works. The only reason to have the aliases for me really was to 
not have target awareness in -drive and -net. So if you're feeling better with 
an arch callback, I'm definitely fine with that too.

Alex




reply via email to

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