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? what is relationship between the two objects? it represent the relation between bus object and device object?
> you effectively embed the other object. You die, the other object dies. > > Your QOMification should also convert NICState to QOM. The NICState > will be a child of the NIC device, and similar for all other > NetClientStates. I'm not sure why you are not converting qemu_new_nic We will not convert -net to QOM, that is, we don't care -net nic. Moreover, -device has exposed network card info. > to QOM, since NICState is-a NetClientState. > > I think this conversion is extremely premature, for multiple reasons. > > 1) together with each conversion, we should make sure that each object > has a canonical path. Without a canonical path you cannot use > object_property_set_link, for example. So far, not even board-level > devices have a canonical path. I'll bump this towards the top of my list. > > 2) the network devices subsystem is among the most complicated. There > is already a pending refactoring for hubs; you are making these changes > on top of hubs but didn't even state this anywhere. Let's concentrate > on one thing at a time, please. good advice. thanks > > 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. > > Paolo -- Regards, Zhi Yong Wu
