From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1gdJ-0002zK-Ge for qemu-devel@nongnu.org; Wed, 15 Aug 2012 12:39:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1gdI-0002u4-F4 for qemu-devel@nongnu.org; Wed, 15 Aug 2012 12:39:49 -0400 Received: from paradis.irqsave.net ([109.190.18.76]:35825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1gdI-0002ty-6P for qemu-devel@nongnu.org; Wed, 15 Aug 2012 12:39:48 -0400 Date: Wed, 15 Aug 2012 18:39:40 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20120815163940.GB2194@irqsave.net> References: <1345042466-31743-1-git-send-email-benoit@irqsave.net> <1345042466-31743-4-git-send-email-benoit@irqsave.net> <502BCD04.1060608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <502BCD04.1060608@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] qemu-img: Add json output option to the info command. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, =?iso-8859-1?Q?Beno=EEt?= Canet , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org, pbonzini@redhat.com, xiawenc@linux.vnet.ibm.com Le Wednesday 15 Aug 2012 =E0 10:23:32 (-0600), Eric Blake a =E9crit : > On 08/15/2012 08:54 AM, Beno=EEt Canet wrote: > > This additionnal --machine=3Djson option make qemu-img info output on > > stdout a JSON formated representation of the image informations. > >=20 > > --machine=3Djson was choosen instead of --format=3Djson because the > > info command already have a -f parameter. >=20 > Do we want a counterpart '--machine=3Dtext' or '--machine=3Dhuman' to > explicitly specify current output format? >=20 > > @@ -1113,10 +1174,20 @@ static int img_info(int argc, char **argv) > > char backing_filename[1024]; > > char backing_filename2[1024]; > > BlockDriverInfo bdi; > > + ImageInfo *image_info; > > =20 > > fmt =3D NULL; > > + machine =3D NULL; > > for(;;) { > > - c =3D getopt(argc, argv, "f:h"); > > + int option_index =3D 0; > > + static struct option long_options[] =3D { > > + {"help", no_argument, 0, 'h'}, > > + {"format", required_argument, 0, 'f'}, > > + {"machine", required_argument, 0, 'm'}, > > + {0, 0, 0, 0} > > + }; > > + c =3D getopt_long(argc, argv, "f:h", > > + long_options, &option_index); >=20 > getopt_long is not in POSIX. Are you sure this will compile on all > target platforms? benoit@Laure:~/qemu$ git grep getopt_long fsdev/virtfs-proxy-helper.c: c =3D getopt_long(argc, argv, "p:nh?f= :s:u:g:", helper_opts, qemu-ga.c: while ((ch =3D getopt_long(argc, argv, sopt, lopt, &opt_ind= )) !=3D -1) { qemu-io.c: while ((c =3D getopt_long(argc, argv, sopt, lopt, &opt_inde= x)) !=3D -1) { qemu-nbd.c: while ((ch =3D getopt_long(argc, argv, sopt, lopt, &opt_in= d)) !=3D -1) { savevm.c:#define getopt_long_only getopt_long A few occurence of getopg_long are already in qemu. Is it a sufficient reason to keep getopt_long ? If not what would be the alternatives ? Beno=EEt >=20 > --=20 > Eric Blake eblake@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >=20