qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: block: format vs. protocol, and how they stack


From: Anthony Liguori
Subject: [Qemu-devel] Re: block: format vs. protocol, and how they stack
Date: Tue, 22 Jun 2010 07:39:58 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]