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. > >> 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? > >> it represent the relation between bus object and device object? > > We're talking about netdevs, bus and object does not matter here no? yeah. > >> We will not convert -net to QOM, that is, we don't care -net nic. > > As long as it works that's fine but... > >> 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. > instances should be QOM objects, including those owned by NICs. > >>> 3) the network devices already support hotplug very well, so it's also >>> not too useful to do them first. Let's first do chardevs. >> >> 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. > > Paolo
-- Regards, Zhi Yong Wu