[Qemu-devel] Fate of the read-only block drivers?

[Qemu-devel] Fate of the read-only block drivers?

[Christoph Hellwig]

Currently we have four very simple, read-only block drivers in the
tree:

 - cloop:
	This one is known buggy for non-trivial use and didn't get
	any chance but the usual API changes and cleanup sweeps
	since it was commited in 2004.

 - dmg:
	This one is really grotty and by auditing the code and comparing
	it to dmg2img completely buggy for non-compressed chunks.  It's
	also missing lots of the features in modern dmg image.  Also
	there's no creation tool for Linux.  No non-trivial commits
	since the initial import in 2004.

 - bochs:
	There is an bximage tools to actually create images for it,
	but not to actually add any content to them.  It had one
	non-trivial commit in 2007 to add support for growable formats
	since it's initial commit in 2004.

 - parallels:
	I can't find any way to actually create the image except with
	the parallels image tool which seems to require a commercial
	parallels license.
	No non-trivial commits since the initial import in 2007.

At this point I'm not sure if it's worth bothering to fix these up,
as they're bitrotted and except for cloop there's no reasy way to
actually create test images for them.

Any good reason to keep them, and if yes any good idea for a test plan
to keep them working?

Re: [Qemu-devel] Fate of the read-only block drivers?

[Kevin Wolf]

Am 05.05.2010 20:27, schrieb Christoph Hellwig:
> Currently we have four very simple, read-only block drivers in the
> tree:
> 
>  - cloop:
> 	This one is known buggy for non-trivial use and didn't get
> 	any chance but the usual API changes and cleanup sweeps
> 	since it was commited in 2004.
> 
>  - dmg:
> 	This one is really grotty and by auditing the code and comparing
> 	it to dmg2img completely buggy for non-compressed chunks.  It's
> 	also missing lots of the features in modern dmg image.  Also
> 	there's no creation tool for Linux.  No non-trivial commits
> 	since the initial import in 2004.
> 
>  - bochs:
> 	There is an bximage tools to actually create images for it,
> 	but not to actually add any content to them.  It had one
> 	non-trivial commit in 2007 to add support for growable formats
> 	since it's initial commit in 2004.
> 
>  - parallels:
> 	I can't find any way to actually create the image except with
> 	the parallels image tool which seems to require a commercial
> 	parallels license.
> 	No non-trivial commits since the initial import in 2007.
> 
> At this point I'm not sure if it's worth bothering to fix these up,
> as they're bitrotted and except for cloop there's no reasy way to
> actually create test images for them.

We can create images at least for cloop and bochs, which is 50%, even
though the latter not automated. (The only way I found was using bochs,
and the biggest challenge there is finding a guest OS that boots up in
finite time. A FreeDOS floppy did the trick for my manual test.)

Likewise, not all of them are known broken, it's only cloop and one path
in dmg. I'm not sure about the good reasons to keep them, but I guess
the code wouldn't exist in the first place if nobody had cared about the
functionality. It's probably easy to remove code that can't possibly
work today, but that's true only for part of this code.

> Any good reason to keep them, and if yes any good idea for a test plan
> to keep them working?

Basically I see two options for testing them:

a) Make the read-write, so you can test consistency of qemu's
implementation. This is what we're doing for formats like VMDK. Probably
not worth it.

b) Put some binary images in the qemu-iotests repository. For each
format we would need someone who owns the respective software and can
convert our test image to that format. For cloop and bochs we can
probably do it ourselves, for dmg and parallels we would need help.

Kevin