From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35910 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OR3CM-00063J-6A for qemu-devel@nongnu.org; Tue, 22 Jun 2010 09:07:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OR3CK-0005Pq-Fq for qemu-devel@nongnu.org; Tue, 22 Jun 2010 09:07:29 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:50041) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OR3CK-0005Pk-Be for qemu-devel@nongnu.org; Tue, 22 Jun 2010 09:07:28 -0400 Received: by iwn10 with SMTP id 10so2201836iwn.4 for ; Tue, 22 Jun 2010 06:07:27 -0700 (PDT) Message-ID: <4C20B592.1040902@codemonkey.ws> Date: Tue, 22 Jun 2010 08:07:30 -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> <4C1F6B36.8070508@codemonkey.ws> <4C1F70AF.8030108@redhat.com> <4C1F866A.7040708@codemonkey.ws> <4C206FF3.4070400@redhat.com> <4C20AF1E.1070204@codemonkey.ws> <4C20B342.5040804@redhat.com> In-Reply-To: <4C20B342.5040804@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/22/2010 07:57 AM, Kevin Wolf wrote: >>> and it will be turned into something sensible automagically (namely >>> adding a file blockdev underneath and passing the file parameter to that >>> one), but if you want to change an option, you need to specify both? >>> >>> -blockdev id=foo,format=qcow2,parent=foo_file >>> -blockdev id=foo_file,format=file,file=foo.qcow2,cache=off >>> >>> What about read-only? >>> >> Good question. If a user specifies file, I think the (or generic block >> layer) should have wide latitude to decide how to creating that backing >> format which could include propagating options that it thinks are >> reasonable (like readonly). >> > Right, if we get to use a default value, we can propagate things that > the generic block layer knows. However, as soon as someone specifies a > protocol explicitly, he'll need to add readonly=on to each -blockdev in > the chain? > Yes. I think once you do an explicit option, you have to be very careful. >> My concern is seeing something like: >> >> -blockdev id=foo,format=qcow2,file=blah.img,funkyopt=value >> >> or: >> >> -blockdev id=foo,format=qcow2,protocol=[file=blah.img,funkyopt=value] >> >> I think the later syntax is overwhelming. If the semantics of the >> former syntax is "passthrough any options we don't understand at this >> layer", I'm afraid it gets too confusing about which level actually >> processed the option (and it certainly doesn't deal with propagation). >> > The former involves definitely too much magic for assigning the options > to the right blockdev. The latter would be more comprehensible, but > isn't really nice either. > > On the other hand, funkyopt might be something as common as cache, and > I'd hate to require specifying the protocol explicitly in a second > -blockdev referenced by another ID when you just want to change the > cache option. > I understand the concern but I think one of the big problems with -drive and bdrv_open today is they are far too magical. We shouldn't make the same mistake again. We ought to keep in my the 80/20 rule. In this case, I'm fairly certain that it's closer to 99% of users are only doing 1% of what is actually possible and generally that's going to either be -hda foo.img or -blockdev file=foo.img,option=value. Regards, Anthony Liguori > Kevin >