Re: [Qemu-devel] [PATCH V6 1/3] Implement sync modes for drive-backup.

[Paolo Bonzini <pbonzini@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 24/07/2013 22:32, Eric Blake ha scritto:
> On 07/24/2013 04:55 AM, Kevin Wolf wrote:
> 
>>> Unconditionally overriding format for NEW_IMAGE_MODE_EXISTING
>>> is definitely wrong. It's the user's choice which COW format to
>>> use for the backup image. There's no reason why it has to be
>>> the same format as the image that is being backed up.
>>> 
>>> Before, bs->drv->format_name was a default for the case where a
>>> new image had to be created and no format was given; and the
>>> format of existing images could be probed. This is still what
>>> makes most sense to me. What's even the goal with this change?
> Furthermore, I'm proposing that for 1.6, we should make the format 
> argument mandatory for drive-backup.  We made it optional for 
> drive-mirror, to allow for probing, but there have been CVEs in the
> past due to probing of a raw file gone wrong.  We can always relax
> a mandatory argument into an optional one in 1.7, if we decide
> that probing can be done safely, but we can never turn an optional
> argument into a mandatory one once the initial release bakes in the
> option.  It would make the code a lot simpler to just have a
> mandatory format argument, instead of having to bake in and
> document hueristics on which format is picked when the caller
> doesn't provide one.

Probing is unsafe by definition, on the other hand we should allow it
for consistency with the rest of the API.

Making the format mandatory for mode != 'existing' is fine, though.
We can relax it later.

For mode = 'existing' we should allow both probing, and using an
explicit format.

Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR8TgEAAoJEBvWZb6bTYbyYcoP/A5whcr0fvd2SBfx71b2xQpZ
/4Ug8c0jjraSSt+IoLMvnwD6EYkHRuXt3qDg1q2R9sIsrjQPaQjZ3PFv2ZFrnj5+
Yrxjzpe6mKQboOWeVEeUBZc1/hvzPrUnsgFf59QnhVjz5piE9xW/c5mRd4/6ij2J
3ngnv1VTB/yoNDbLoUpbMKr4EOMZKTsR0HR96QzEYRMZafL52hihnygyNXtOV84B
sfBrGC68Q9S+3Fj9Yb0qhRWZnEP8xQP8KhA5uO6jlgowUqal2JjIUDFh7/dQn0Mt
b1YlDT0a9KRfZnKc7Q4V37vALkd750kcMgoR3IxcHuuHomKf08UG5tLmYEDoMd/G
+FQol5QL/fnBjOD2uf+oN43DeYXlv3yL4iVChPhlyxBVI9aDZseli90tlJ0sSRtS
4+rEdXhtzhEXavpJMu9Vijfkzi3wYwNWdRViEoBo6ifuh9ZsIsmIMmHaWabn2J2i
rEmpB/VAFhK3XNR6OXegyG0PrYYMqWU92W7INJx0fe91lslX8xzShElL4MHRaRmU
5OiyiVKFjC5XUCTQAwwHaKTxWJ/U8rCQj8Axia5dh6SHunZMmaDLAgpKBK229A1i
X+tuv4PI8vyeWJM3uhIDVSAswqUS41sVmnDYimCzvOj8tI/gudktygS0r1nkTgBW
ePDuM7nPNHm3ifFuaPn9
=fY6P
-----END PGP SIGNATURE-----