From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIN11-00006J-4N for qemu-devel@nongnu.org; Mon, 02 Feb 2015 14:50:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIN0x-0001Hs-TJ for qemu-devel@nongnu.org; Mon, 02 Feb 2015 14:50:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIN0x-0001Ho-KQ for qemu-devel@nongnu.org; Mon, 02 Feb 2015 14:50:31 -0500 Date: Mon, 2 Feb 2015 20:50:26 +0100 From: Kevin Wolf Message-ID: <20150202195026.GH19586@noname.redhat.com> References: <1422284444-12529-1-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422284444-12529-1-git-send-email-mreitz@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 00/14] block: Remove "growable", add blk_new_open() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Stefano Stabellini , qemu-devel@nongnu.org, Stefan Hajnoczi , Markus Armbruster Am 26.01.2015 um 16:00 hat Max Reitz geschrieben: > This series removes the "growable" field from the BlockDriverState > object. Its use was to clamp guest requests against the limits of the > BDS; however, this can now be done more easily by moving those checks > into the BlockBackend functions. > > In a future series, "growable" may be reintroduced (maybe with a > different name); it will then signify whether a BDS is able to grow (in > contrast to the current "growable", which signifies whether it is > allowed to). Maybe I will add it to the BlockDriver instead of the BDS, > though. > > To be able to remove that field, qemu-io needs to be converted to > BlockBackend, which is done by this series as well. While working on > that I decided to convert blk_new_with_bs()+bdrv_open() to > blk_new_open(). I was skeptical about that decision at first, but it > seems good now that I was able to replace nearly every blk_new_with_bs() > call by blk_new_open(). In a future series I may try to convert some > remaining bdrv_open() calls to blk_new_open() as well. (And, in fact, in > a future series I *will* replace the last remaining blk_new_with_bs() > outside of blk_new_open() by blk_new_open().) > > Finally, the question needs to be asked: If, after this series, every > BDS is allowed to grow, are there any users which do not use BB, but > should still be disallowed from reading/writing beyond a BDS's limits? > The only users I could see were the block jobs. Some of them should > indeed be converted to BB; but none of them takes a user-supplied offset > or size, all work on the full BDS (or only on parts which have been > modified, etc.). Therefore, it is by design impossible for them to > exceed the BDS's limits, which makes making all BDS's growable safe. Patches that I didn't comment on (all except 4, 5, 6, 9, 10, 13) are, assuming that you address Eric's comments, if any: Reviewed-by: Kevin Wolf