|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH 04/14] qdev: take ownership of id pointer |
Date: | Tue, 20 Sep 2011 15:21:16 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110904 Red Hat/3.1.14-1.el6_1 Thunderbird/3.1.14 |
On 09/20/11 15:04, Anthony Liguori wrote:
On 09/20/2011 01:36 AM, Gerd Hoffmann wrote:On 09/19/11 18:27, Anthony Liguori wrote:On 09/19/2011 02:34 AM, Gerd Hoffmann wrote: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 cycleYes.such that you cannot accidentally create a non-device QemuOpts that conflicts with the id of a device?Device QemuOpts have their own id namespace, so this is just about conflicts within devices. This ... device_add e1000,id=nic1 device_del nic1 device_add e1000,id=nic1 ... will work only if you free the QemuOpts when deleting a device, otherwise QemuOpts will complain that nic1 is used already.But we can just verify that the id specified for qdev is unique at creation time and fail creation if it isn't, no? Since not all devices are assigned names via qemuopts, that seems like a safer approach anyway.
I think that happens anyway (didn't check the source though).Problem is that QemuOpts wants IDs being unique too, so keep the QemuOpts hanging around instead of releasing them makes QemuOpts complain about nic1 not being unique although there isn't such a device in qdev space. Oh, and not releasing the QemuOpts would also leak memory on each hot-unplug.
cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |