From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54534 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKXWY-0002bG-HF for qemu-devel@nongnu.org; Mon, 22 Nov 2010 09:37:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKXWX-0002CG-H4 for qemu-devel@nongnu.org; Mon, 22 Nov 2010 09:37:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKXWX-0002C2-7R for qemu-devel@nongnu.org; Mon, 22 Nov 2010 09:37:41 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oAMEbdGx003346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Nov 2010 09:37:39 -0500 Message-ID: <4CEA806C.8040501@redhat.com> Date: Mon, 22 Nov 2010 15:38:36 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/1] NBD isn't used by qemu-img, so don't link qemu-img against NBD objects References: <1290184248-30078-1-git-send-email-Jes.Sorensen@redhat.com> <4CEA6102.3020709@redhat.com> <4CEA794F.40506@redhat.com> <4CEA7AFD.2050609@redhat.com> <4CEA7DBD.9020904@redhat.com> In-Reply-To: <4CEA7DBD.9020904@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: qemu-devel@nongnu.org Am 22.11.2010 15:27, schrieb Jes Sorensen: > On 11/22/10 15:15, Kevin Wolf wrote: >> Am 22.11.2010 15:08, schrieb Jes Sorensen: >>> I am aware of that, but what on earth is qemu-img doing with NBD in the >>> first place? Doesn't make much sense to me. >> >> The same as it's doing with file, host_device or http: Accessing images. >> Start an NBD server (e.g. with qemu-nbd) and try something like qemu >> -hda nbd:localhost. This is how you use the nbd block driver. > > Well ok, seems a really backwards way to try and shoot yourself in the > foot, but ok, maybe I should redo the patch to simply allow compiling > NBD out instead. You're free to dislike NBD as much as you want. Just compiling it out unconditionally and calling it a cleanup is a bit too much. ;-) A configure option for disabling NBD sounds reasonable, though I'm not sure what you're trying to achieve with it. It doesn't have any external dependencies that you could avoid this way, does it? Kevin