From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55180 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OQhCS-0004sv-KW for qemu-devel@nongnu.org; Mon, 21 Jun 2010 09:38:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OQhCN-0006CW-EF for qemu-devel@nongnu.org; Mon, 21 Jun 2010 09:38:08 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:50791) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OQhCN-0006CR-8P for qemu-devel@nongnu.org; Mon, 21 Jun 2010 09:38:03 -0400 Received: by iwn10 with SMTP id 10so1060065iwn.4 for ; Mon, 21 Jun 2010 06:38:02 -0700 (PDT) Message-ID: <4C1F6B36.8070508@codemonkey.ws> Date: Mon, 21 Jun 2010 08:37:58 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4C1DF2C1.5040505@redhat.com> <4C1F2093.3060807@redhat.com> <4C1F6482.7020406@codemonkey.ws> <4C1F6973.5020003@redhat.com> In-Reply-To: <4C1F6973.5020003@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: block: format vs. protocol, and how they stack List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Christoph Hellwig , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Gerd Hoffmann , Avi Kivity On 06/21/2010 08:30 AM, Kevin Wolf wrote: > Am 21.06.2010 15:09, schrieb Anthony Liguori: > >> On 06/21/2010 03:19 AM, Kevin Wolf wrote: >> >>> Am 20.06.2010 12:51, schrieb Avi Kivity: >>> >>> >>>> On 06/18/2010 03:59 PM, Markus Armbruster wrote: >>>> >>>> >>>>> The code is pretty confused about format vs. protocol, and so are we. >>>>> Let's try to figure them out. >>>>> >>>>> From cruising altitude, all this format, protocol, stacking business >>>>> doesn't matter. We provide a bunch of arguments, and get an image. >>>>> >>>>> If you look more closely, providing that image involves sub-tasks. One >>>>> is to haul bits. Another one is to translate between bits in different >>>>> formats. >>>>> >>>>> Working hypothesis: >>>>> >>>>> * A protocol hauls image bits. Examples: file, host_device, nbd. >>>>> >>>>> * A format translates image formats. Examples: raw, qcow2. >>>>> >>>>> >>>>> >>>>> >>>> Is there a reason to make the distinction? Is there a reason to expose >>>> the distinction to the user? >>>> >>>> >>> There are good reasons to make that distinction internally. There's no >>> need to expose it to the user - the question is if it helps or not. >>> >>> >> If we drop the distinction, then I think the remaining issue is how to >> expose the stacking to a user. >> >> Right now, we could have a syntax like: >> >> -blockdev format=file,file=image.qcow2,id=base \ >> -blockdev format=qcow2,backing_dev=base,id=blk1 >> >> backing_dev is a sucky name, but hopefully the point is clear. I think >> the following would be a better user syntax: >> >> -blockdev format=qcow2,file=image.qcow2,id=blk1 >> >> I think the easiest way to support this is to make qcow2 take a file >> parameter and have it open the file with default options. For users >> that need anything more sophisticated a user has to use the former syntax. >> > Not only qcow2, but also raw, qcow, vmdk, vdi, bochs, cow, dmg, ... > > In short: Any format needs an underlying protocol. You may not call it > by its name, but that's effectively what you'd implement. And if you > implemented it in each format driver instead of generic code, you'd be > doing a bad implementation. > Sure. I don't think it would be all that difficult to implement in common code. > The more I think about it, the more I believe that the logic of how qemu > handles things is made much clearer if we actually call it by its name > and expose the distinction to the user. > > "If there is no protocol specified, qemu will pick one automatically" > vs. "If you specify an image in raw, qcow2, qcow, vmdk, vdi, bochs, cow, > dmg or blkdebug format and you have no backing_dev specified, qemu will > pick one automatically; it won't do so for images in file, host_device, > host_flopy, host_cdrom, nbd, http or vvfat format." It's an easy choice. > Are you basically saying: [1] -blockdev format=qcow2,protocol=file,file=foo.img,id=blk1 Because what I was suggesting is that we don't allow protocol=XX here. We would try to guess the protocol from foo.img. If a user wishes to override this, they should do the full syntax of: [2] -blockdev protocol=host_dev,file=/dev/sda,id=base \ -blockdev format=qcow2,backing_dev=base,id=blk1 But we're also suggesting s/protocol/format/ because the distinction doesn't seem to be important unless you try to support syntax [1] and you need a mechanism to specify the leaf format (which you're calling a protocol). Regards, Anthony Liguori >> We can still support format probing. We should drop any support for >> parameter passing via file name too (with nbd and vfat). >> > For -blockdev, agreed. We need to retain it with -drive, though. > > Kevin >