From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=39703 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OQyZ7-00023q-UH
	for qemu-devel@nongnu.org; Tue, 22 Jun 2010 04:10:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OQyZ6-00044z-ET
	for qemu-devel@nongnu.org; Tue, 22 Jun 2010 04:10:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:47212)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OQyZ6-00044s-7u
	for qemu-devel@nongnu.org; Tue, 22 Jun 2010 04:10:40 -0400
Message-ID: <4C206FF3.4070400@redhat.com>
Date: Tue, 22 Jun 2010 10:10:27 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <m3ocf8ts1y.fsf@blackfin.pond.sub.org>
	<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>
In-Reply-To: <4C1F866A.7040708@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: block: format vs. protocol, and how they stack
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Christoph Hellwig <chellwig@redhat.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Avi Kivity <avi@redhat.com>

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

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? Is it something that must be specified for each
single node in the chain to actually get the right semantics?

Kevin