From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5ggs-0000cZ-Ue for qemu-devel@nongnu.org; Mon, 19 Sep 2011 12:27:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5ggr-0000fy-Ne for qemu-devel@nongnu.org; Mon, 19 Sep 2011 12:27:30 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:57707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5ggr-0000fu-D3 for qemu-devel@nongnu.org; Mon, 19 Sep 2011 12:27:29 -0400 Received: by gxk26 with SMTP id 26so6332413gxk.4 for ; Mon, 19 Sep 2011 09:27:28 -0700 (PDT) Message-ID: <4E776D6D.2040702@codemonkey.ws> Date: Mon, 19 Sep 2011 11:27:25 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1316188834-13675-1-git-send-email-aliguori@us.ibm.com> <1316188834-13675-5-git-send-email-aliguori@us.ibm.com> <4E76F074.4030801@redhat.com> In-Reply-To: <4E76F074.4030801@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/14] qdev: take ownership of id pointer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini On 09/19/2011 02:34 AM, Gerd Hoffmann wrote: > On 09/16/11 18:00, Anthony Liguori wrote: >> qdev has this quirk that it owns a seemingly arbitrary QemuOpts pointer. That's >> because qdev expects a static string for the id (which really makes no sense >> since ids are supposed to be provided by the user). Instead of managing just >> the id pointer, we currently take ownership of the entire QemuOpts structure >> that was used to create the device just to keep the name around. > > FYI: Keeping the pointer to the QemuOpts has one more reason: It will free the > QemuOpts on hot-unplug, which is needed to free the id from QemuOpts point of > view, which in turn allows to re-use the id when hot-plugging the same (or > another) device later on. You mean, tie QemuOpts life cycle to devices life cycle such that you cannot accidentally create a non-device QemuOpts that conflicts with the id of a device? Regard, Anthony Liguori > > cheers, > Gerd > >