qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Reitz
Subject: Re: [Qemu-block] [RFC PATCH 0/2] Early release of -drive QemuOpts
Date: Fri, 22 Jan 2016 23:38:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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. ;-)

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]