From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpdKo-0003Xk-Oj for qemu-devel@nongnu.org; Fri, 13 Jul 2012 06:43:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpdKi-0004sN-UR for qemu-devel@nongnu.org; Fri, 13 Jul 2012 06:42:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpdKi-0004sI-KU for qemu-devel@nongnu.org; Fri, 13 Jul 2012 06:42:48 -0400 Message-ID: <4FFFFBA1.9030007@redhat.com> Date: Fri, 13 Jul 2012 12:42:41 +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> In-Reply-To: <20120713094315.GA16172@stefanha-thinkpad.localdomain> 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: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Paolo Bonzini , Anthony Liguori , Christoph Hellwig , Wenchao Xia Am 13.07.2012 11:43, schrieb Stefan Hajnoczi: > On Fri, Jul 13, 2012 at 11:27:55AM +0200, Christoph Hellwig wrote: >> On Fri, Jul 13, 2012 at 10:13:15AM +0100, Stefan Hajnoczi wrote: >>> How is that different from all the qemu-io commands? >> >> qemu-io has no modes to just dumb the output without additional >> information / statistics or for the write case just take user input >> instead of a pattern. I actually tried to add raw arguments to >> qemu-io, which still worked ou ok for reads but started to get >> fairly ugly for the write. >> >> What I use in production right now is a trivial qemu-cat tool that >> just does the raw reads and writes, but I think adding it as a new >> sub command to qemu-img instead of another tool seems a bit cleaner. >> >> If you and Kevin or Anthony disagree and want the qemu-cat tool I can >> submit a patch for that instead. > > Okay, I see what you mean. I have used the hex output mode (when you > use the verbose option) but it's not raw. > > Sounds like you want a qemu-dd :). I think adding that to qemu-img is > fine though since it's already the tool that users are familiar with for > image file manipulation and that gets shipped. 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. If you need to get data from stdin or output it to stdout, then it might not be the right solution. Kevin