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
