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. > [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.
