From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51916 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OR2li-0002kA-Ca for qemu-devel@nongnu.org; Tue, 22 Jun 2010 08:39:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OR2lg-0000QR-Nv for qemu-devel@nongnu.org; Tue, 22 Jun 2010 08:39:57 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:60319) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OR2lg-0000QF-HE for qemu-devel@nongnu.org; Tue, 22 Jun 2010 08:39:56 -0400 Received: by iwn10 with SMTP id 10so2177117iwn.4 for ; Tue, 22 Jun 2010 05:39:55 -0700 (PDT) Message-ID: <4C20AF1E.1070204@codemonkey.ws> Date: Tue, 22 Jun 2010 07:39: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> <4C1F6B36.8070508@codemonkey.ws> <4C1F70AF.8030108@redhat.com> <4C1F866A.7040708@codemonkey.ws> <4C206FF3.4070400@redhat.com> In-Reply-To: <4C206FF3.4070400@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 03:10 AM, Kevin Wolf wrote: > Am 21.06.2010 17:34, schrieb Anthony Liguori: > >> On 06/21/2010 09:01 AM, Kevin Wolf wrote: >> >>> No, what I'm saying is that even in your model >>> >>> -blockdev format=qcow2,file=image.qcow2,id=blk1 >>> >>> becomes qcow2 -> file automatically, whereas >>> >>> -blockdev format=vvfat,file=/tmp/dir/,id=blk1 >>> >>> doesn't become vvfat -> file, but stays just vvfat. >>> >>> >> I should say, that -blockdev format= vs. -blockdev transport= is >> definitely at a place where I don't care that much. >> >> The things that I think are most important are: >> >> 1) That we have structured options that map well to config file without >> trickery to do nesting >> 2) That we don't automagically pass options through from the first layer >> down to subsequent layers >> > Does this mean that you need to specify the protocol explicitly for any > non-trivial case? So if you want to use just default for everything you > can use > > -blockdev id=foo,format=qcow2,file=foo.qcow2 > Yes. I think we should explicitly support an option like file. > 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). 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). Regards, Anthony Liguori > Is it something that must be specified for each > single node in the chain to actually get the right semantics? > > Kevin >