From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhwIQ-0001Qb-8C for qemu-devel@nongnu.org; Wed, 07 May 2014 03:29:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhwIK-0004IK-07 for qemu-devel@nongnu.org; Wed, 07 May 2014 03:29:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhwIJ-0004I8-Om for qemu-devel@nongnu.org; Wed, 07 May 2014 03:29:35 -0400 Date: Wed, 7 May 2014 09:29:29 +0200 From: Stefan Hajnoczi Message-ID: <20140507072929.GA27925@stefanha-thinkpad.muc.redhat.com> References: <1397155423-29713-1-git-send-email-mreitz@redhat.com> <5367B9FB.6060606@redhat.com> <20140506081058.GA8923@stefanha-thinkpad.redhat.com> <5369210E.2070407@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5369210E.2070407@redhat.com> 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: Max Reitz Cc: Kevin Wolf , qemu-devel@nongnu.org, =?iso-8859-1?Q?Beno=EEt?= Canet On Tue, May 06, 2014 at 07:51:10PM +0200, Max Reitz wrote: > 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 filen= ames > >>>are JSON objects prefixed by "json:". The objects are used as option= s > >>>for opening another block device which will be the child of the JSON > >>>device. Regarding this child device, the JSON driver behaves nearly = the > >>>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 b= lock > >>>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 give= n, > >>>e.g., for backing files. Using this should obviously be the exceptio= n, > >>>but it is nice to have if actually needed. > >>Ping =E2=80=93 I do understand that Kevin has reservations against th= is > >>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. >=20 > Okay, if you think the same, I guess I'll have to rewrite this > series. I agree that including this functionality in bdrv_open() is > the nicer alternative from the user's point of view, whereas I think > using a separate block driver results in nicer code. >=20 > I'll rewrite this series and then we'll see how bad it actually looks. = ;-) Thanks! Stefan