qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for host device model
Date: Tue, 27 Mar 2012 12:15:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

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
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
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.

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.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]