qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] Early release of -drive QemuOpts
Date: Fri, 22 Jan 2016 23:38:34 +0100	[thread overview]
Message-ID: <56A2AF6A.5090004@redhat.com> (raw)
In-Reply-To: <56A23621.1010406@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-01-22 22:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 17:37 [Qemu-devel] [RFC PATCH 0/2] Early release of -drive QemuOpts Paolo Bonzini
2016-01-08 17:37 ` [Qemu-devel] [PATCH 1/2] block: detach devices from DriveInfo at unrealize time Paolo Bonzini
2016-01-08 17:37 ` [Qemu-devel] [PATCH 2/2] block: remove legacy_dinfo at blk_detach_dev time Paolo Bonzini
2016-01-22 14:01 ` [Qemu-devel] [RFC PATCH 0/2] Early release of -drive QemuOpts Paolo Bonzini
2016-01-22 22:38   ` Max Reitz [this message]
2016-02-04 23:01     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A2AF6A.5090004@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).