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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/21/2010 11:01 AM, Christoph Hellwig wrote:
> On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
>    
>> There's just a couple cases we should consider:
>>
>> [1] -blockdev format=raw,file=/dev/cdrom,id=blk1
>>      
>    
>> For [1], we just defaulting transport to file is would not give us the
>> same semantics we have today.  Is that desirable?
>>      
> By mentioning the host devices you're opening another can of worms here.
> The host devices are another special case which is a rather problematic.
> I think the best we can do is to eliminate the different protocols for
> the host devices and fold them into file.  For one the basic host
> device Blockdriver really doesn't make any sense to be different from
> file.  The only differences are:
>
>   - host_device sets the no_zero_init flag.  This is something we could easily
>     do per-instance with an S_ISCHR || S_ISBLK check in the right place
>   - host_device has a different ->create method.  Instead of truncating
>     the file to the image size it does an llseek to figure if the new
>     size fits.  Again, this could be one method with an S_ISCHR || S_ISBLK
>     block check.  (and btw, the llseek seems to be wrong for some weirded
>     unix variants, compare to raw_getlength).
>   - host_device implements the ioctl and aio_ioctl methods.  We'll need
>     them for file anyway once my discard support lands.
>
> Now what's more interesting than the plain host_device are the magic
> cdrom and floppy devices.  These offer bdrv_is_inserted /
> bdrv_media_changed / bdrv_eject eject methods, and once it a while do
> some magic in bdrv_open.  We could easily key those off with a small
> host_device_operations structure inside raw-posix.c (which should be
> rename file-posix.c these days).  That would make the whole model a
> lot more consistent, and we could get rid of all the device probing
> special casing in the block layer which, which is a complete mess
> due to the Windows vs Unix differences.
>    

I fully agree here.  The result would be a much cleaner distinction 
between format and transport once you get rid of the host device stuff.

>> [2] -blockdev format=vvfat,file=/path/to/directory,id=blk1
>>
>>
>> It's not clear to me why [2] should be transport=vvfat.  vvfat really
>> isn't a transport.
>>      
> Well, it's a wart if you want to be exact.  But in the above model
> it's a clearly a transport.  It does not take an arbitrary BlockDriver
> on the layer below it but implements it's own I/O methods not using the
> qemu block layer - it maps from an image file the filesystem namespace.
> Similar to file connects to a file on the local system and nbd/http
> connects an image on a remote system.
>
>    
>> What about things like blkdebug and if we had
>> something like a ramdisk?
>>      
> A ramdisk again is a transport into a file that's purely in-memory.
> You can trivially run any format we have ontop of it.
>
> blkdebug in it's current form is a trivial image format, just like raw
> in the above terminology.  It takes an arbitrary qemu BlockDriver as
> input and then stacks on top.
>
> Think of a protocol/transport as the thing that implements the lowest
> layer of the qemu block I/O stack which then maps to native I/O methods.
>    

Yes, we're back to the whole discussion of leaf vs. non-leaf nodes.  The 
fundamental question is, why make this distinction visible to the user?  
Why does the user care if something is a leaf vs. a non-leaf node?

Regards,

Anthony Liguori