From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCTR3-0003mz-3O for qemu-devel@nongnu.org; Tue, 27 Mar 2012 06:15:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCTQw-00048k-NY for qemu-devel@nongnu.org; Tue, 27 Mar 2012 06:15:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCTQw-00048S-FS for qemu-devel@nongnu.org; Tue, 27 Mar 2012 06:15:22 -0400 Message-ID: <4F719328.8010409@redhat.com> Date: Tue, 27 Mar 2012 12:15:04 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1332740423-8426-1-git-send-email-zwu.kernel@gmail.com> <1332740423-8426-2-git-send-email-zwu.kernel@gmail.com> <4F71791C.1060601@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for host device model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu Cc: Zhi Yong Wu , qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com 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 property. > IMHO, i don't fully understand what link mean. What is the > difference between it and Child. Can you elaborate this? link is a pointer to another object. child 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