From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33638 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKSCE-0001rW-2h for qemu-devel@nongnu.org; Fri, 04 Jun 2010 04:24:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKSCC-0004CE-47 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 04:24:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24142) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKSCB-0004Bw-T0 for qemu-devel@nongnu.org; Fri, 04 Jun 2010 04:24:04 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 13/13] blockdev: New -blockdev to define a host block device References: <1275497729-13120-1-git-send-email-armbru@redhat.com> <1275497729-13120-14-git-send-email-armbru@redhat.com> <20100603080053.GA5151@lst.de> Date: Fri, 04 Jun 2010 10:23:58 +0200 In-Reply-To: <20100603080053.GA5151@lst.de> (Christoph Hellwig's message of "Thu, 3 Jun 2010 10:00:53 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: kwolf@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com Christoph Hellwig writes: > On Wed, Jun 02, 2010 at 06:55:29PM +0200, Markus Armbruster wrote: >> Existing -drive defines both host and guest part. To make it work >> with -device, we created if=none. But all this does is peel off guest >> device selection. The other guest properties such as geometry, >> removable vs. fixed media, and serial number are still in the wrong >> place. >> >> Instead of overloading -drive even further, create a new, clean option >> to define a host block device. -drive stays around unchanged for >> command line convenience and backwards compatibility. >> >> This is just a first step. Future work includes: > > One thing we really needs is a protocol option. The current colon > syntax means we can't support filenames with colons in them which > users keep requesting. By making the protocol a separate option > we can sort this out. You're absolutely right. I'll look into it.