From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2MfI-0001pW-Ka for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:37:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2MfH-0004Oe-0Z for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:37:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2MfG-0004OX-Nd for qemu-devel@nongnu.org; Thu, 25 Jul 2013 10:37:10 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6PEb9vd031437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Jul 2013 10:37:10 -0400 Message-ID: <51F13804.4060906@redhat.com> Date: Thu, 25 Jul 2013 16:36:52 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374530960-22031-1-git-send-email-imain@redhat.com> <1374530960-22031-2-git-send-email-imain@redhat.com> <20130724105543.GA3623@dhcp-200-207.str.redhat.com> <51F039F5.90109@redhat.com> In-Reply-To: <51F039F5.90109@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V6 1/3] Implement sync modes for drive-backup. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , famz@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, Ian Main , stefanha@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-----