From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpduZ-0005ss-DD for qemu-devel@nongnu.org; Fri, 13 Jul 2012 07:19:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpduV-0006zp-Ct for qemu-devel@nongnu.org; Fri, 13 Jul 2012 07:19:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpduV-0006zi-36 for qemu-devel@nongnu.org; Fri, 13 Jul 2012 07:19:47 -0400 Message-ID: <50000441.6090107@redhat.com> Date: Fri, 13 Jul 2012 13:19:29 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4FFA9C30.2070201@linux.vnet.ibm.com> <20120709143607.GB5226@lst.de> <20120713091315.GB15503@stefanha-thinkpad.localdomain> <20120713092755.GA479@lst.de> <20120713094315.GA16172@stefanha-thinkpad.localdomain> <4FFFFBA1.9030007@redhat.com> <20120713105556.GA2025@lst.de> In-Reply-To: <20120713105556.GA2025@lst.de> Content-Type: text/plain; charset=ISO-8859-1 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: Christoph Hellwig Cc: qemu-devel@nongnu.org, Paolo Bonzini , Anthony Liguori , Stefan Hajnoczi , Wenchao Xia Am 13.07.2012 12:55, schrieb Christoph Hellwig: > On Fri, Jul 13, 2012 at 12:42:41PM +0200, Kevin Wolf wrote: >> It still feels a bit more like qemu-io-style operations. Not sure what >> your use case looks like exactly, but adding a qemu-io command that >> reads data from a file and writes it at a given offset into the images >> (or vice versa) should be easy. This would be more or less a qemu-dd. > > We already have that if you read/write the whole image, it's called > qemu-img convert. Hm. Fair point, I guess. Though qemu-img tends to have commands that deal with complete disks instead of just areas. >> If you need to get data from stdin or output it to stdout, then it might >> not be the right solution. > > That is the use case. We could appromite it by writing a temp file and > using qemu-img convert, but that's not very efficient. Yeah, it's not what you want then. So the question is whether to have it integrated in qemu-img or standalone. I'm undecided: Having everything in one well-known tool has its advantages. But then, a qemu-dd that feels like a real dd, just that it opens image formats with the right driver instead of always using raw, certainly sounds attractive, too. Let's wait a bit for more opinions. If there aren't any - you write the code, you decide. Kevin