qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, kwolf@redhat.com
Subject: Re: [Qemu-devel] [PATCH v12 02/10] block: Update comments on BDRV_BLOCK_* meanings
Date: Fri, 5 May 2017 15:13:04 -0500	[thread overview]
Message-ID: <c81a7c3e-5eae-5740-a600-53729fe8c6e7@redhat.com> (raw)
In-Reply-To: <53789feb-7a2d-09ae-cc03-8cde0b1b85e4@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

On 05/05/2017 03:06 PM, Max Reitz wrote:
> On 04.05.2017 05:07, Eric Blake wrote:
>> We had some conflicting documentation: a nice 8-way table that
>> described all possible combinations of DATA, ZERO, and
>> OFFSET_VALID, contrasted with text that implied that OFFSET_VALID
>> always meant raw data could be read directly.  Furthermore, the
>> text refers a lot to bs->file, even though the interface was
>> updated back in 67a0fd2a to let the driver pass back which BDS (not
>> necessarily bs->file).
> 
> Not sure about my English skills here, but is this missing a verb? ("to
> pass back which BDS...")

maybe s/which/a specific/

> 
>>                         As the 8-way table is the intended
>> semantics, simplify the rest of the text to get rid of the
>> confusion.
>>
>> ALLOCATED is always set by the block layer for convenience (drivers
>> do not have to worry about it). RAW is used only internally, but
> 
> Just one space after the period? How inconsistent! :-)

But do commit messages really count?  :)


>> + * Internal flag:
>> + * BDRV_BLOCK_RAW: used internally to indicate that the request was
>> + *                 answered by a passthrough driver such as raw and that the
> 
> s/passthrough/filter/? But I'm not even sure myself. Well, "passthrough"
> is a safe bet, so let's just go with it.

Calling 'raw' a filter driver is a bit weird - but in one sense, it is a
no-op filter (filter the protocol layer into the format layer by doing
nothing).  Meanwhile 'commit' certainly sounds like more of a filter
than a passthrough.  I could go either way, and filter is slightly
shorter.  If there's a real reason to respin the series, 'filter' seems
reasonable if we're worried about line length, otherwise I'm just as
inclined to leave it alone.

> 
> With the commit message fixed or a “no it's fine”:
> 
> Reviewed-by: Max Reitz <mreitz@redhat.com>
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2017-05-05 20:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04  3:07 [Qemu-devel] [PATCH v12 00/10] qcow2 zero-cluster tweaks [was add blkdebug tests] Eric Blake
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 01/10] qcow2: Use consistent switch indentation Eric Blake
2017-05-05 19:42   ` Max Reitz
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 02/10] block: Update comments on BDRV_BLOCK_* meanings Eric Blake
2017-05-05 20:06   ` Max Reitz
2017-05-05 20:13     ` Eric Blake [this message]
2017-05-05 20:23       ` Max Reitz
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 03/10] qcow2: Correctly report status of preallocated zero clusters Eric Blake
2017-05-05 20:24   ` Max Reitz
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 04/10] qcow2: Make distinction between zero cluster types obvious Eric Blake
2017-05-05 20:51   ` Max Reitz
2017-05-06 20:30     ` Eric Blake
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 05/10] qcow2: Optimize zero_single_l2() to minimize L2 churn Eric Blake
2017-05-05 20:55   ` Max Reitz
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 06/10] iotests: Improve _filter_qemu_img_map Eric Blake
2017-05-05 20:58   ` Max Reitz
2017-05-05 21:06     ` Eric Blake
2017-05-05 21:07       ` Max Reitz
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 07/10] iotests: Add test 179 to cover write zeroes with unmap Eric Blake
2017-05-05 21:24   ` Max Reitz
2017-05-05 22:29   ` Max Reitz
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 08/10] qcow2: Optimize write zero of unaligned tail cluster Eric Blake
2017-05-05 22:06   ` Max Reitz
2017-05-05 22:41     ` Eric Blake
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 09/10] qcow2: Assert that cluster operations are aligned Eric Blake
2017-05-04  3:07 ` [Qemu-devel] [PATCH v12 10/10] qcow2: Discard/zero clusters by byte count Eric Blake
2017-05-05 22:18 ` [Qemu-devel] [PATCH v12 00/10] qcow2 zero-cluster tweaks [was add blkdebug tests] Max Reitz
2017-05-05 22:43   ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c81a7c3e-5eae-5740-a600-53729fe8c6e7@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).