From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YG9ZG-0000Cv-Hp for qemu-devel@nongnu.org; Tue, 27 Jan 2015 12:04:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YG9ZB-0003KU-Gw for qemu-devel@nongnu.org; Tue, 27 Jan 2015 12:04:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YG9ZB-0003KL-8Z for qemu-devel@nongnu.org; Tue, 27 Jan 2015 12:04:41 -0500 Message-ID: <54C7C524.4030509@redhat.com> Date: Tue, 27 Jan 2015 12:04:36 -0500 From: Max Reitz MIME-Version: 1.0 References: <1422284444-12529-1-git-send-email-mreitz@redhat.com> <1422284444-12529-11-git-send-email-mreitz@redhat.com> <54C7C40C.8040601@redhat.com> In-Reply-To: <54C7C40C.8040601@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 10/14] qemu-io: Remove "growable" option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , Markus Armbruster , Stefan Hajnoczi , Stefano Stabellini On 2015-01-27 at 11:59, Eric Blake wrote: > On 01/26/2015 08:00 AM, Max Reitz wrote: >> Remove "growable" option from the "open" command and from the qemu-io >> command line. qemu-io is about to be converted to BlockBackend which >> will make sure that no request exceeds the image size, so the only way >> to keep "growable" would be to use BlockBackend if it is not given and >> to directly access the BDS if it is. >> >> qemu-io is a debugging tool, therefore removing a rarely used option >> will have only a very small impact, if any. There was only one >> qemu-iotest which used the option; since it is not critical, this patch >> just removes it. >> >> Signed-off-by: Max Reitz >> --- > Reviewed-by: Eric Blake > > Do we want to ever reuse the test number that you are deleting? Good question, I think I have talked about that with Kevin before. It would not hurt too much if we were to accidentally reuse the test case number, most certainly not here in upstream. However, for all downstream versions of qemu, this might make adding the new test 16 difficult; but certainly not impossible (if someone is affected by this issue, he/she can just use 999 or something). So we may want to keep in mind not to reuse number 16, but if someone does, so be it. Max