From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47144)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1WkWoB-00050K-7e
	for qemu-devel@nongnu.org; Wed, 14 May 2014 06:53:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1WkWo4-0006t7-S8
	for qemu-devel@nongnu.org; Wed, 14 May 2014 06:53:11 -0400
Received: from mx1.redhat.com ([209.132.183.28]:61444)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1WkWo4-0006t3-Kr
	for qemu-devel@nongnu.org; Wed, 14 May 2014 06:53:04 -0400
Date: Wed, 14 May 2014 12:52:58 +0200
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20140514105258.GG3610@noname.redhat.com>
References: <1399572762-13990-1-git-send-email-mreitz@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1399572762-13990-1-git-send-email-mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 0/4] block: Allow JSON filenames
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, =?iso-8859-1?Q?Beno=EEt?= Canet <benoit@irqsave.net>

Am 08.05.2014 um 20:12 hat Max Reitz geschrieben:
> This series acts as some kind of alternative or v6 to the "block/json:
> Add JSON protocol driver" series. It makes bdrv_open() parse filenames
> prefixed by "json:" as JSON objects (discarding the prefix beforehand)
> and then use the resulting QDict as the options for the block device to
> be opened with a NULL filename.
> 
> The purpose of this is that it may sometimes be desirable to specify
> options for a block device where only a filename can be given, e.g., for
> backing files. Using this should obviously be the exception, but it is
> nice to have if actually needed.
> 
> 
> After having written this series, I do indeed agree that it is much
> nicer than the old version of having a dedicated "virtual" block driver
> for this purpose.
> 
> Patches 1 and 2 are taken directly from the block/json v3, patch 4 has
> been enriched by an additional scenario (options given both directly and
> through the filename) and its comments have been adapted to the new
> implementation.

Thanks, applied all to the block branch.

Kevin