From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoTE5-0005jh-MB for qemu-devel@nongnu.org; Tue, 10 Jul 2012 01:43:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoTE3-000273-Ua for qemu-devel@nongnu.org; Tue, 10 Jul 2012 01:43:09 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:36732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoTE3-00026Y-Ay for qemu-devel@nongnu.org; Tue, 10 Jul 2012 01:43:07 -0400 Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Jul 2012 06:29:23 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6A5YVho35913932 for ; Tue, 10 Jul 2012 15:34:31 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6A5gLtc014131 for ; Tue, 10 Jul 2012 15:42:21 +1000 Received: from [127.0.0.1] (wenchaox.cn.ibm.com [9.115.122.127]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6A5gHbR014031 for ; Tue, 10 Jul 2012 15:42:21 +1000 Message-ID: <4FFBC0B7.4090204@linux.vnet.ibm.com> Date: Tue, 10 Jul 2012 13:42:15 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <4FFA9C30.2070201@linux.vnet.ibm.com> <20120709143607.GB5226@lst.de> In-Reply-To: <20120709143607.GB5226@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: qemu-devel@nongnu.org 于 2012-7-9 22:36, Christoph Hellwig 写道: > On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote: >> Hi, Paolo and folks, >> qemu have good capabilities to access different virtual disks, I want >> to expose its block layer API to let 3rd party program linked in, such >> as management stack or block tools, to access images data directly. >> >> Following is the objects: >> (1) API to write/read block device at offset. >> (2) Determine the image type,qcow2/qed/raw >> (3) Determine which blocks are allocated. >> (4) Determine backing file. > > Sounds like you want a procedural interface for that. At least for (1) > I have patches I'll submit soon to add qemu img read/write commands. Yes, the purpose is introduce API interface about block data, the operation was supposed to happen frequently, a linked-in library may be better than process output string parsing in performance. > > -- Best Regards Wenchao Xia