From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57012 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOx1G-0001Fi-S1 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 14:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOx1F-000605-Aq for qemu-devel@nongnu.org; Wed, 16 Jun 2010 14:07:22 -0400 Received: from mail-yw0-f190.google.com ([209.85.211.190]:46500) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOx1F-0005zx-7Y for qemu-devel@nongnu.org; Wed, 16 Jun 2010 14:07:21 -0400 Received: by ywh28 with SMTP id 28so4988033ywh.28 for ; Wed, 16 Jun 2010 11:07:20 -0700 (PDT) Message-ID: <4C1912D5.5090102@codemonkey.ws> Date: Wed, 16 Jun 2010 13:07:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs References: <4C1783CC.7070307@redhat.com> <4C18B375.4050900@redhat.com> <4C18D483.4080200@codemonkey.ws> <4C18D85A.1050208@redhat.com> In-Reply-To: <4C18D85A.1050208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Christoph Hellwig , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Avi Kivity , Gerd Hoffmann On 06/16/2010 08:57 AM, Kevin Wolf wrote: > Am 16.06.2010 15:41, schrieb Anthony Liguori: > >> On 06/16/2010 07:41 AM, Markus Armbruster wrote: >> >>> Kevin Wolf writes: >>> >>>> But it's painful to type for the user. After all -blockdev on the >>>> command line is for the user, as tools should use QMP. Also note that >>>> this syntax mixes format and protocol options on one line which I >>>> consider confusing at best. >>>> >>>> As I told Markus already in private before he posted this, I prefer the >>>> bracket solution for its clarity and simplicity, even though it comes at >>>> the cost of having additional characters that need to be escaped. >>>> >>>> >>> I dont't think 1. is less painful than 3. Let's compare the two: >>> >>> * Single protocol: identical with suitable syntactical sugar, namely >>> >>> -blockdev id=blk1,file=fedora.img >>> >>> >> First, let me say that -blockdev is not something that I believe is >> targeted at users. It's incredible unfair for us to expect a user to type: >> >> -blockdev id=blk1,file=fedora.img -device ide-drive,drive=blk1,bus=0,unit=0 >> >> Instead of: >> >> -hda fedora.img >> > Sure thing, as long as -hda provides all the options. I usually start > off with -hda, but after a while I need to set some option and switch to > -drive. This is what most users are using today. > > If we're not going to extend -drive to cover all features, then users > will (have to) start using -blockdev. > > >> I had to look up the device syntax just to write that. There's no way >> users are going to do this. We should drop any notion of syntactical >> sugar IMHO. -blockdev is for management tools, scripts, and as an >> infrastructure for config files. >> > In that case, let's go for the JSON version. We need separate options to map to a configuration file. We already represent trees of information in the configuration files and there's an established way of doing this (naming nodes with 'id' and then referencing them as a parent). > But it requires that > everything that -blockdev provides is accessible with -drive, too (or > that we're okay with users hating us). > I'm happy for -drive to die. I think we should support -hda and -blockdev. -blockdev should be optimized for config files, not single argument input. IOW: [blockdev "blk2"] format = "raw" file = "/path/to/base.img" cache = "writeback" [blockdev "blk1"] format = "qcow2" file = "/path/to/leaf.img" cache="off" backing_dev = "blk2" [device "disk1"] driver = "ide-drive" blockdev = "blk1" bus = "0" unit = "0" Or: qemu -blockdev id=blk2,format=raw,file=/path/to/base.img,cache=writeback \ -blockdev id=blk1,format=qcow2,file=/path/to/leaf.img,backing_dev=blk2 \ -device ide-disk,blockdev=blk1,bus=0,unit=0 Or: qemu -hda /path/to/leaf.img And if a user really feels they need to modify the defaults, they can do: qemu -hda /path/to/leaf.img -writeconfig myconf.cfg And edit from there. >> But honestly, I'm thoroughly confused about the distinction between >> protocol and format. I had thought that protocols were a type of format >> and I'm not sure why we're making a distinction. >> > Technically, they are mostly the same. Logically, they are not. You have > one image format driver (raw, qcow2, ...) that accesses its image data > through one or more stacked protocols (file, host_device, nbd, http, ...). > > In the past we've had quite some trouble because there was no clear > distinction. raw and file was the same. If you had an image on a block > device, you were asking for trouble. > As Christoph mentions, we really don't have stacked protocols and I'm not sure they make sense. >>> I sure prefer the latter. The brackets look like noise. You need to >>> understand protocol stacking for them to make any sense. >>> >>> Regarding confusion caused by mixing format and protocol options: yes, >>> the brackets force you to distinguish between protocol options and >>> other options. But I doubt that'll reduce confusion here. Either you >>> understand protocols. Then I doubt you need brackets to unconfuse >>> you. Or you don't understand protocols. Then whether to put an >>> option inside or outside the brackets is voodoo. >>> >>> >> If the above is necessary just to create a raw image, then we're doing >> something wrong in the block layer. If should be possible to just say: >> >> -blockdev id=blk1,format=raw,file=fedora.img >> > I think we all agree on this (although it contradicts what you said > above, because file is a property of the protocol). The question is how > to specify protocols explicitly. > I think raw doesn't make very much sense then. What's the point of it if it's just a thin wrapper around a protocol? Regards, Anthony Liguori > Kevin >