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.