From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXYW5-0003fo-69 for qemu-devel@nongnu.org; Thu, 13 Dec 2018 16:27:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXYW2-0003Hh-IO for qemu-devel@nongnu.org; Thu, 13 Dec 2018 16:27:33 -0500 References: <20181212220410.569069-1-eblake@redhat.com> <20181213104704.GD5171@redhat.com> <20181213140513.GD5427@linux.fritz.box> From: Eric Blake Message-ID: Date: Thu, 13 Dec 2018 15:27:22 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nir Soffer , Kevin Wolf Cc: "Daniel P. Berrange" , QEMU Developers , qemu-block , Max Reitz On 12/13/18 11:44 AM, Nir Soffer wrote: >> The things is, qemu-io was never meant to be used by other >> applications that need to process the results, it's a tool for testing >> and debugging. If we had meant it to be used by other programs, we would >> have given it a machine-friendly interface. >> >> The machine-friendly interface to the QEMU block layer is qemu-nbd. >> > > nbd is awesome, but much more complicated to use for testing. You need to: > > 1. start qemu-nbd > 2. wait until it is ready > 3. use nbd client (we have one now), or connect the qemu-nbd to /dev/ndbX, > which on > Fedora 28 leaves stale /dev/nbdX devices after disconnection > (I reported this few month ago here). Is that true even when you use 'qemu-nbd -d /dev/nbdX' after you are done? > 4. finally disconnect and wait until qemu-nbd terminates > > qemu-io is so much easier to use, we need to make it more machine friendly. Or rather, if there is something that a machine needs to drive, we should figure out if qemu-img can be taught to do it instead of hacking around the issue with qemu-io. When it comes to extracting portions of a disk, qemu-img convert coupled with the raw driver's offset/length gets us quite a bit of functionality - even if it's clunky to come up with the command line, it can be programmed, and doesn't suffer from having to post-process arbitrary qemu-io output changes. >> The human interface of qemu-io is honestly just not the right tool for >> the job, and adding one-off tweaks to make it a little bit less horrible >> to use for machines isn't the right approach because it's still not a >> proper machine protocol. >> > > Add --output json? Who's volunteering to do it? I've got too much else going on to spend time on such a project. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org