Hi,
Oh, and not
releasing the QemuOpts would also leak memory on each hot-unplug.
If you look at my patch, opts is freed at the end of device_add so there
is no leak.
Ah, ok. Missed that.
cheers,
Gerd
On 09/20/2011 08:21 AM, Gerd Hoffmann wrote:
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
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 t
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,
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
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).
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
