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

[Anthony Liguori]

On 06/21/2010 08:30 AM, Kevin Wolf wrote:
> Am 21.06.2010 15:09, schrieb Anthony Liguori:
>    
> > On 06/21/2010 03:19 AM, Kevin Wolf wrote:
> >      
> > > Am 20.06.2010 12:51, schrieb Avi Kivity:
> > >
> > >        
> > > > On 06/18/2010 03:59 PM, Markus Armbruster wrote:
> > > >
> > > >          
> > > > > The code is pretty confused about format vs. protocol, and so are we.
> > > > > Let's try to figure them out.
> > > > >
> > > > >    From cruising altitude, all this format, protocol, stacking business
> > > > > doesn't matter.  We provide a bunch of arguments, and get an image.
> > > > >
> > > > > If you look more closely, providing that image involves sub-tasks.  One
> > > > > is to haul bits.  Another one is to translate between bits in different
> > > > > formats.
> > > > >
> > > > > Working hypothesis:
> > > > >
> > > > > * A protocol hauls image bits.  Examples: file, host_device, nbd.
> > > > >
> > > > > * A format translates image formats.  Examples: raw, qcow2.
> > > > >
> > > > >
> > > > >
> > > > >            
> > > > Is there a reason to make the distinction?  Is there a reason to expose
> > > > the distinction to the user?
> > > >
> > > >          
> > > There are good reasons to make that distinction internally. There's no
> > > need to expose it to the user - the question is if it helps or not.
> > >
> > >        
> > If we drop the distinction, then I think the remaining issue is how to
> > expose the stacking to a user.
> >
> > Right now, we could have a syntax like:
> >
> > -blockdev format=file,file=image.qcow2,id=base  \
> > -blockdev format=qcow2,backing_dev=base,id=blk1
> >
> > backing_dev is a sucky name, but hopefully the point is clear.  I think
> > the following would be a better user syntax:
> >
> > -blockdev format=qcow2,file=image.qcow2,id=blk1
> >
> > I think the easiest way to support this is to make qcow2 take a file
> > parameter and have it open the file with default options.  For users
> > that need anything more sophisticated a user has to use the former syntax.
> >      
> Not only qcow2, but also raw, qcow, vmdk, vdi, bochs, cow, dmg, ...
>
> In short: Any format needs an underlying protocol. You may not call it
> by its name, but that's effectively what you'd implement. And if you
> implemented it in each format driver instead of generic code, you'd be
> doing a bad implementation.
>    

Sure.  I don't think it would be all that difficult to implement in 
common code.

> The more I think about it, the more I believe that the logic of how qemu
> handles things is made much clearer if we actually call it by its name
> and expose the distinction to the user.
>
> "If there is no protocol specified, qemu will pick one automatically"
> vs. "If you specify an image in raw, qcow2, qcow, vmdk, vdi, bochs, cow,
> dmg or blkdebug format and you have no backing_dev specified, qemu will
> pick one automatically; it won't do so for images in file, host_device,
> host_flopy, host_cdrom, nbd, http or vvfat format." It's an easy choice.
>    

Are you basically saying:

[1] -blockdev format=qcow2,protocol=file,file=foo.img,id=blk1

Because what I was suggesting is that we don't allow protocol=XX here.  
We would try to guess the protocol from foo.img.  If a user wishes to 
override this, they should do the full syntax of:

[2] -blockdev protocol=host_dev,file=/dev/sda,id=base \
-blockdev format=qcow2,backing_dev=base,id=blk1

But we're also suggesting s/protocol/format/ because the distinction 
doesn't seem to be important unless you try to support syntax [1] and 
you need a mechanism to specify the leaf format (which you're calling a 
protocol).

Regards,

Anthony Liguori

> > We can still support format probing.  We should drop any support for
> > parameter passing via file name too (with nbd and vfat).
> >      
> For -blockdev, agreed. We need to retain it with -drive, though.
>
> Kevin
>