From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhjWW-0008Sj-F7 for qemu-devel@nongnu.org; Tue, 06 May 2014 13:51:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhjWQ-000128-5a for qemu-devel@nongnu.org; Tue, 06 May 2014 13:51:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43846) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhjWP-00011x-SD for qemu-devel@nongnu.org; Tue, 06 May 2014 13:51:18 -0400 Message-ID: <5369210E.2070407@redhat.com> Date: Tue, 06 May 2014 19:51:10 +0200 From: Max Reitz MIME-Version: 1.0 References: <1397155423-29713-1-git-send-email-mreitz@redhat.com> <5367B9FB.6060606@redhat.com> <20140506081058.GA8923@stefanha-thinkpad.redhat.com> In-Reply-To: <20140506081058.GA8923@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 00/12] block/json: Add JSON protocol driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel@nongnu.org, =?UTF-8?B?QmVubw==?= =?UTF-8?B?w650IENhbmV0?= On 06.05.2014 10:10, Stefan Hajnoczi wrote: > On Mon, May 05, 2014 at 06:19:07PM +0200, Max Reitz wrote: >> On 10.04.2014 20:43, Max Reitz wrote: >>> This series adds a passthrough JSON protocol block driver. Its filena= mes >>> are JSON objects prefixed by "json:". The objects are used as options >>> for opening another block device which will be the child of the JSON >>> device. Regarding this child device, the JSON driver behaves nearly t= he >>> same as raw_bsd in that it is just a passthrough driver. The only >>> difference is probably that the JSON driver identifies itself as a bl= ock >>> filter, in contrast to raw_bsd. >>> >>> The purpose of this driver 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. >> Ping =E2=80=93 I do understand that Kevin has reservations against thi= s >> series, but as long as he doesn't explicitly ask me to reimplement >> this in bdrv_open() without an own block driver (which I'd more or >> less gladly do), I do not see issues why this series should not be >> merged. > I haven't reviewed it further because it seems like a kludge (that we > have to keep supporting once it's merged). Was hoping you and Kevin > will come up with a long-term fix instead. Okay, if you think the same, I guess I'll have to rewrite this series. I=20 agree that including this functionality in bdrv_open() is the nicer=20 alternative from the user's point of view, whereas I think using a=20 separate block driver results in nicer code. I'll rewrite this series and then we'll see how bad it actually looks. ;-= ) Max