On Tue, Mar 27, 2012 at 10:50 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 27/03/2012 16:18, Zhi Yong Wu ha scritto: >> On Tue, Mar 27, 2012 at 9:58 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> Il 27/03/2012 13:59, Zhi Yong Wu ha scritto: >>>> On Tue, Mar 27, 2012 at 6:15 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >>>>> Il 27/03/2012 11:06, Zhi Yong Wu ha scritto: >>>>>>>>>> +#define DEFINE_HOSTDEV_PROP_PEER(_n, _s, _f) \ >>>>>>>>>> + DEFINE_HOSTDEV_PROP(_n, _s, _f, hostdev_prop_netdev, >>>>>>>>>> NetClientState*) >>>>>>>> >>>>>>>> This should be simply a link<NetDev> property. >>>>>> IMHO, i don't fully understand what link<NetDev> mean. What is the >>>>>> difference between it and Child<NetDev>. Can you elaborate this? >>>>> >>>>> link<NetDev> is a pointer to another object. child<NetDev> means that >>>> Where are link<NetDev> used? >>> >>> The peer property needs to be one. >> sorry, i don't get what it means. > > Links are pointers. As you convert host devices to QOM, pointer > properties such as drive or chardev need to become links. Peer is > another pointer property that needs to become a link. It makes sense to me, thanks. > >>>> what is relationship between the two objects? >>> >>> A has a pointer to B. >> >> I knew this, but can you say one example in QEMU device model? I >> checked QEMU code, and found that those link functions in object.c are >> not currently used. right? > > Yes, that's correct. Everything that uses PROP_PTR needs to become a But i didn't see that that stuff which uses PROP_PTR become a link in current QEMU code. For example: static Property apic_properties_common[] = { ...... DEFINE_PROP_PTR("cpu_env", APICCommonState, cpu_env), ..... DEFINE_PROP_END_OF_LIST(), };
It define one PROP_PTR cpu_env, but i didn't see stuff which made it become one link. Did i miss anything? > link. We cannot do that yet because devices do not yet have a canonical > path. Cannonical path means that it is one absolute path or partial path? > >>>> Moreover, -device has exposed network card info. >>> >>> ... this is extremely confused. Each NIC device has a NIC-type >>> NetClientState. If NetClientState is converted to QOM, all of its >> The original idea about -netdev QOM is to convert NetClientState to >> QOM, but now this idea seems to be changed. > > I cannot parse this at all. You have not converted all of > NetClientState to QOM, have you? No. I am not sure if we need to convert all and we need to know what the benefit is. > >>>> We hope that -netdev options info can be configurated or changed >>>> purely via QOM, not command line. >>> >>> Yes, but does it buy anything or it is just a nice exercise? >> >> buy anything? sorry, i don't understand this. > > What's the advantage? Converting chardev would give hotplug. What can > we do with a QOMified netdev that we cannot do now? It can be configurated or changed purely via QOM, this is one of the advantages by itself. And I think that it should also give hotplug. > > Paolo -- Regards, Zhi Yong Wu