From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dSlBT-0004GD-Ex for qemu-devel@nongnu.org; Wed, 05 Jul 2017 10:21:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dSlBS-0000h7-IL for qemu-devel@nongnu.org; Wed, 05 Jul 2017 10:21:39 -0400 Date: Wed, 5 Jul 2017 22:21:24 +0800 From: Fam Zheng Message-ID: <20170705142124.GA13548@lemon.lan> References: <20170703221456.30817-1-eblake@redhat.com> <20170703221456.30817-4-eblake@redhat.com> <20170704070643.GB10298@lemon.lan> <6aafcf61-7923-23c1-496d-6f2c195149d1@redhat.com> <20170705120725.GF29382@lemon.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2 03/15] block: Add flag to avoid wasted work in bdrv_is_allocated() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, qemu-block@nongnu.org, el13635@mail.ntua.gr, qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , jsnow@redhat.com On Wed, 07/05 09:01, Eric Blake wrote: > On 07/05/2017 07:07 AM, Fam Zheng wrote: > >>> > >>> Sorry for bikeshedding. > >> > >> Not a problem, I also had some double-takes in writing my own code > >> trying to remember which way I wanted the 'allocation' boolean to be > >> set, so coming up with a more intuitive name/default state in order to > >> help legibility is worth it. Do any of my above suggestions sound better? > >> > > > > I'd vote for "mapping" because it has a close connection with offset (as in > > BDRV_BLOCK_OFFSET_VALID). > > > > Or simply call it "offset" and if false, never return BDRV_BLOCK_OFFSET_VALID. > > Well, there ARE drivers that WANT to return BDRV_BLOCK_OFFSET_VALID > regardless of the state of the boolean (namely, any driver that also > returns BDRV_BLOCK_RAW, to hint that this is a passthrough and the query > should be repeated at the next BDS in the chain). So stating that > 'offset' is false MUST preclude BDRV_BLOCK_OFFSET_VALID is a bit too > strong, but I can probably come up with appropriate wording that meets > in the middle ground (if 'offset' is true, then make all efforts to > include BDRV_BLOCK_OFFSET_VALID in the return if that is possible; if it > is false, then omitting the flag in order to get a larger pnum is > acceptable)). Yes you are totally right, I thought that too after replied. Fam