From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQzMN-00021F-HE for qemu-devel@nongnu.org; Tue, 01 Oct 2013 08:47:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VQzMH-0005ou-GV for qemu-devel@nongnu.org; Tue, 01 Oct 2013 08:47:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQzMH-0005op-6x for qemu-devel@nongnu.org; Tue, 01 Oct 2013 08:47:21 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r91ClKJ2002712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Oct 2013 08:47:20 -0400 Message-ID: <524AC455.9060609@redhat.com> Date: Tue, 01 Oct 2013 14:47:17 +0200 From: Max Reitz MIME-Version: 1.0 References: <1380630722-19430-1-git-send-email-mreitz@redhat.com> <1380630722-19430-6-git-send-email-mreitz@redhat.com> In-Reply-To: <1380630722-19430-6-git-send-email-mreitz@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 5/6] qemu-iotests: Discard specific info in _img_info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi On 2013-10-01 14:32, Max Reitz wrote: > In _img_info, filter out additional information specific to the image > format provided by qemu-img info, since tests designed for multiple > image formats would produce different outputs for every image format > otherwise. > > Signed-off-by: Max Reitz Ah, I just noticed I forgot to include a sample of what is to be=20 stripped away, so this will have to do for now: All existing tests using qemu-img info rely on it not emitting image=20 format specific information. Therefore, this data has to be stripped away. In a human-readable dump, that information will always be last for each=20 "image information block" (multiple blocks are emitted when looking at=20 the backing file chain). Every block is seperated by an empty line.=20 Therefore, in this case, everything starting with the line "Format=20 specific information:" up to that empty line (or EOF, if it's the last=20 block) has to be stripped. The JSON dump will always emit "pretty" JSON data. Therefore, the ending=20 brace of every object will be indented as much as the object itself is=20 (and every line in between has more indentation). Thus, in this case, we=20 have to strip all the data beginning with ' *"format-specific": {' until=20 a line ' *},' appears which is indented just as much as the former was. Hm, now that I think of it=E2=80=A6 Actually, the ending line is rather '= *},?',=20 since the comma is "optional", depending on whether it is the last=20 object or not. Well, I think this calls for v7, then. I'll include this=20 description in patch v7 5/6. Max