From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us7Mk-0003TP-Bn for qemu-devel@nongnu.org; Thu, 27 Jun 2013 04:15:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Us7Mh-0003Xh-Br for qemu-devel@nongnu.org; Thu, 27 Jun 2013 04:15:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us7Mh-0003XO-1S for qemu-devel@nongnu.org; Thu, 27 Jun 2013 04:15:39 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5R8FceF011845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Jun 2013 04:15:38 -0400 Date: Thu, 27 Jun 2013 10:15:36 +0200 From: Stefan Hajnoczi Message-ID: <20130627081536.GE13780@stefanha-thinkpad.redhat.com> References: <1372219161-12209-1-git-send-email-famz@redhat.com> <1372219161-12209-2-git-send-email-famz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1372219161-12209-2-git-send-email-famz@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: kwolf@redhat.com, obarenbo@redhat.com, armbru@redhat.com, roliveri@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, pmyers@redhat.com, imain@redhat.com, pbonzini@redhat.com On Wed, Jun 26, 2013 at 11:59:19AM +0800, Fam Zheng wrote: > Add target-id (optional) to drive-backup command, to make the target bs > a named drive so that we can operate on it (e.g. export with NBD). > > Signed-off-by: Fam Zheng > --- > blockdev.c | 4 +++- > qapi-schema.json | 7 +++++-- > qmp-commands.hx | 3 ++- > 3 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/blockdev.c b/blockdev.c > index b3a57e0..5e694f3 100644 > --- a/blockdev.c > +++ b/blockdev.c > @@ -935,6 +935,7 @@ static void drive_backup_prepare(BlkTransactionState *common, Error **errp) > backup = common->action->drive_backup; > > qmp_drive_backup(backup->device, backup->target, > + backup->has_target_id, backup->target_id, > backup->has_format, backup->format, > backup->has_mode, backup->mode, > backup->has_speed, backup->speed, > @@ -1420,6 +1421,7 @@ void qmp_block_commit(const char *device, > } > > void qmp_drive_backup(const char *device, const char *target, > + bool has_target_id, const char *target_id, > bool has_format, const char *format, > bool has_mode, enum NewImageMode mode, > bool has_speed, int64_t speed, > @@ -1494,7 +1496,7 @@ void qmp_drive_backup(const char *device, const char *target, > return; > } > > - target_bs = bdrv_new(""); > + target_bs = bdrv_new(has_target_id ? target_id : ""); This raises a new issue: Now that the target can be named, what happens when the user issues a monitor command, e.g. drive-del, block-resize, or drive-backup :)? We have a clumsy form of protection with bdrv_set_in_use(). It makes several monitor commands refuse with -EBUSY. Perhaps we should have a command permission set so it's possible to allow/deny specific commands. Stefan