Ryan Harper writes:
> * Markus Armbruster [2011-03-24 07:27]:
>> Whoops, almost missed this. Best to cc: me to avoid that.
>>
>
> It was sent directly to you:
>
>> Sender: qemu-devel-bounces+ryanh=us.ibm@nongnu.org
>> From: Ryan Harper
>> S
* Markus Armbruster [2011-03-24 07:27]:
> Whoops, almost missed this. Best to cc: me to avoid that.
>
It was sent directly to you:
> Sender: qemu-devel-bounces+ryanh=us.ibm@nongnu.org
> From: Ryan Harper
> Subject: Re: [Qemu-devel] [PATCH v2] Do not delete BlockD
Whoops, almost missed this. Best to cc: me to avoid that.
Ryan Harper writes:
> * Markus Armbruster [2011-03-15 04:48]:
>> Sorry for the long delay, I was out of action for a week.
>>
>> Ryan Harper writes:
>>
>> > When removing a drive from the host-side via drive_del we currently have
>>
* Markus Armbruster [2011-03-15 04:48]:
> Sorry for the long delay, I was out of action for a week.
>
> Ryan Harper writes:
>
> > When removing a drive from the host-side via drive_del we currently have the
> > following path:
> >
> > drive_del
> > qemu_aio_flush()
> > bdrv_close()
> > drive_un
Sorry for the long delay, I was out of action for a week.
Ryan Harper writes:
> When removing a drive from the host-side via drive_del we currently have the
> following path:
>
> drive_del
> qemu_aio_flush()
> bdrv_close()
> drive_uninit()
> bdrv_delete()
>
> When we bdrv_delete() we end up qemu
When removing a drive from the host-side via drive_del we currently have the
following path:
drive_del
qemu_aio_flush()
bdrv_close()
drive_uninit()
bdrv_delete()
When we bdrv_delete() we end up qemu_free() the BlockDriverState pointer
however, the block devices retain a copy of this pointer, see
