From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40041)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1WiSWt-0007h6-Cs
	for qemu-devel@nongnu.org; Thu, 08 May 2014 13:54:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1WiSWj-0003eh-Sc
	for qemu-devel@nongnu.org; Thu, 08 May 2014 13:54:47 -0400
Received: from mx1.redhat.com ([209.132.183.28]:45036)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1WiSWj-0003eM-Kv
	for qemu-devel@nongnu.org; Thu, 08 May 2014 13:54:37 -0400
Message-ID: <536BC4D5.7020205@redhat.com>
Date: Thu, 08 May 2014 19:54:29 +0200
From: Max Reitz <mreitz@redhat.com>
MIME-Version: 1.0
References: <1399404625-6093-1-git-send-email-mreitz@redhat.com>
	<1399404625-6093-4-git-send-email-mreitz@redhat.com>
	<53693EC1.3080303@redhat.com>
	<20140507083958.GD4045@noname.str.redhat.com>
In-Reply-To: <20140507083958.GD4045@noname.str.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 3/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: Kevin Wolf <kwolf@redhat.com>, Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, =?ISO-8859-1?Q?Beno=EEt_Canet?= <benoit@irqsave.net>

On 07.05.2014 10:39, Kevin Wolf wrote:
> Am 06.05.2014 um 21:57 hat Eric Blake geschrieben:
>> On 05/06/2014 01:30 PM, Max Reitz wrote:
>>> If the filename given to bdrv_open() is prefixed with "json:", parse the
>>> rest as a JSON object and use the result as the options QDict.
>>>
>>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>>> ---
>>>   block.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 41 insertions(+)
>>>
>>>   /*
>>>    * Opens a disk image (raw, qcow2, vmdk, ...)
>>>    *
>>> @@ -1337,6 +1364,20 @@ int bdrv_open(BlockDriverState **pbs, const char *filename,
>>>           options = qdict_new();
>>>       }
>>>   
>>> +    if (filename && g_str_has_prefix(filename, "json:")) {
>>> +        QDict *json_options = parse_json_filename(filename, &local_err);
>>> +        if (local_err) {
>>> +            ret = -EINVAL;
>>> +            goto fail;
>>> +        }
>>> +
>>> +        qdict_join(options, json_options, true);
>>> +        assert(qdict_size(json_options) == 0);
>> Would it be better to pass false to qdict_join(), and then raise an
>> error if the user specified conflicting options?  For example (untested,
>> just typing off the top of my head here),
>>
>> -drive
>> file='json:{"driver":"qcow2","file.filename":"foo","backing.file.driver":"raw"}',backing.file.driver=qcow2
>>
>> looks like it specifies conflicting backing.file.driver options.
>> Passing true means that qdict_join silently overwrites the value in
>> options to instead be the value in the json string; passing false means
>> you could flag the user error.
> Isn't the more realistic case, that 'file' is actually the backing file
> string stored in an image, and the overwriting option comes from the
> command line? In this case, I think we want to allow overriding the
> option stored in the qcow2 file.

Yes, you're probably right. I'll drop outputting an error message for 
conflicting entries from v2 in v3.

Max