|
From: | Max Reitz |
Subject: | Re: [PATCH v2 3/6] block: Clarify that @bytes is no limit on *pnum |
Date: | Mon, 12 Jul 2021 09:47:05 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 28.06.21 21:10, Eric Blake wrote:
+++ b/include/block/block_int.h @@ -347,6 +347,11 @@ struct BlockDriver { * clamped to bdrv_getlength() and aligned to request_alignment, * as well as non-NULL pnum, map, and file; in turn, the driver * must return an error or set pnum to an aligned non-zero value. + * + * Note that @bytes is just a hint on how big of a region the + * caller wants to inspect. It is not a limit on *pnum. + * Implementations are free to return larger values of *pnum if + * doing so does not incur a performance penalty.Worth mention that the cache will benefit of it?Oh, right, absolutely. Like so: "block/io.c's bdrv_co_block_status() will clamp *pnum before returning it to its caller, but it itself can still make use of the unclamped *pnum value. Specifically, the block-status cache for protocol nodes will benefit from storing as large a region as possible."How about this tweak to the wording to make it flow a little better: block/io.c's bdrv_co_block_status() will utilize an unclamped *pnum value for the block-status cache on protocol nodes, prior to clamping *pnum for return to its caller.
Sure, thanks! Max
[Prev in Thread] | Current Thread | [Next in Thread] |