From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqg37-0006yz-3k for qemu-devel@nongnu.org; Mon, 16 Jul 2012 03:48:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sqg35-0006nc-Ty for qemu-devel@nongnu.org; Mon, 16 Jul 2012 03:48:57 -0400 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:47045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sqg35-0006nN-Be for qemu-devel@nongnu.org; Mon, 16 Jul 2012 03:48:55 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 16 Jul 2012 07:41:58 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6G7mhpg8520014 for ; Mon, 16 Jul 2012 17:48:44 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6G7mhtJ013406 for ; Mon, 16 Jul 2012 17:48:43 +1000 Message-ID: <5003C758.8020502@linux.vnet.ibm.com> Date: Mon, 16 Jul 2012 15:48:40 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <4FFA9C30.2070201@linux.vnet.ibm.com> <20120709092705.GG16198@redhat.com> <4FFBBF8C.8080708@linux.vnet.ibm.com> <4FFBD729.8000309@redhat.com> <20120713091247.GA15503@stefanha-thinkpad.localdomain> <20120713091640.GD2317@redhat.com> In-Reply-To: <20120713091640.GD2317@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org > On Fri, Jul 13, 2012 at 10:12:47AM +0100, Stefan Hajnoczi wrote: >> On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote: >>> Il 10/07/2012 07:37, Wenchao Xia ha scritto: >>>>> >>>>> For getting the other metadata about the disk image you mention, another >>>>> possibility to is just make 'qemu-img info' return the data in a machine >>>>> parseable format, ie JSON& make a client API for extracting data from >>>>> this JSON document. >>>>> >>>> Thank u for the idea. The .so is introduced to let program access the >>>> image more directly, parsing string is not so fast and it depends on >>>> another program's stdout output, I hope to get a faster way. >>> >>> I doubt you actually have profiled it. >> >> I think speed is not the issue, instead it's just providing an API that >> external programs can use. Management tools, backup software, custom >> administration tools, etc. It's convenient to have an API. > > Actually I think speed could well be quite relevant. In large deployments > it would not be surpising to see 1000's of images in a directory. If you > want to be able to query metadata about all of them at once, then being > able to open()+read(4k)+close() 1000 times is going to be dramatically > faster than doing fork()+execve(qemu-img) 1000 times. > I tried to avoid fork() and execv() in the library as much as possible. Dealing with another program's string output will cost quite some codes about its timeout or exception error, more "native" code seems better to me. > NB, I still think qemu-img info should be able to return a JSON parsable > data format, regardless of what any block library does. An option to qemu-img to specify output format may be a good way. > > Daniel > -- Best Regards Wenchao Xia