Re: [Qemu-devel] [RFC PATCH 0/2] Early release of -drive QemuOpts

[Paolo Bonzini <pbonzini@redhat.com>]

On 22/01/2016 23:38, Max Reitz wrote:
> On 22.01.2016 15:01, Paolo Bonzini wrote:
>>
>>
>> On 08/01/2016 18:37, Paolo Bonzini wrote:
>>> In short, this patch gets rid of blockdev_mark_auto_del and
>>> blockdev_auto_del.
>>>
>>> With these patches, it is possible to create a new -drive with the same
>>> id as soon as the DEVICE_DELETED event is delivered (which equals to
>>> unrealize).
>>>
>>> I'm sorry I'm not able to explain the history (and probably do not
>>> understand the full ramifications) of this.  That's why this is just
>>> an RFC.
>>>
>>> The idea here is that reference counting the BlockBackend is enough to
>>> defer the deletion of the block device as much as necessary; anticipating
>>> the demise of the DriveInfo is not a problem, and has the desired effect
>>> of freeing the QemuOpts.
>>>
>>> Paolo
>>>
>>> Paolo Bonzini (2):
>>>   block: detach devices from DriveInfo at unrealize time
>>>   block: remove legacy_dinfo at blk_detach_dev time
>>>
>>>  block/block-backend.c            | 14 ++++++++----
>>>  blockdev.c                       | 26 ++++++++------------------
>>>  hw/block/virtio-blk.c            |  4 +++-
>>>  hw/block/xen_disk.c              |  1 +
>>>  hw/core/qdev-properties-system.c |  2 +-
>>>  hw/ide/piix.c                    |  3 +++
>>>  hw/scsi/scsi-bus.c               |  4 +++-
>>>  hw/usb/dev-storage.c             |  3 ++-
>>>  include/sysemu/blockdev.h        |  5 ++---
>>>  9 files changed, 33 insertions(+), 29 deletions(-)
>>>
>>
>> Ping?  Any comments or other kinds of review? :)
> 
> I skimmed it last week and I remember that I found the idea sound and
> didn't have any objections; but that I didn't feel confident for a R-b
> or explicit comment, because I don't think I understand the full
> ramifications of it either. ;-)

It has some failures after the latest block pull request.  I'll see
what's going on.

Paolo