Re: [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for host device model

[Zhi Yong Wu]

On Tue, Mar 27, 2012 at 6:15 PM, Paolo Bonzini <address@hidden> 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