qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org
Cc: eblake@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/3] doc: Document generic -blockdev options
Date: Fri, 23 Sep 2016 19:15:59 +0200	[thread overview]
Message-ID: <1c843f20-a649-91da-67b6-9aa594a23e94@redhat.com> (raw)
In-Reply-To: <1474646781-18951-3-git-send-email-kwolf@redhat.com>

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

On 23.09.2016 18:06, Kevin Wolf wrote:
> This adds documentation for the -blockdev options that apply to all
> nodes independent of the block driver used.
> 
> All options that are shared by -blockdev and -drive are now explained in
> the section for -blockdev. The documentation of -drive mentions that all
> -blockdev options are accepted as well.
> 
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> ---
>  qemu-options.hx | 98 ++++++++++++++++++++++++++++++++++++++++-----------------
>  1 file changed, 69 insertions(+), 29 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 542c483..8766589 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -523,6 +523,43 @@ STEXI
>  @findex -blockdev
>  
>  Define a new block driver node.
> +
> +@table @option
> +@item Valid options for any block driver node:
> +
> +@table @code
> +@item driver
> +Specifies the block driver to use for the given node.
> +@item node-name
> +This defines the name of the block driver node by which it will be referenced
> +later. The name must be unique, i.e. it must not match the name of a different
> +block driver node, or (if you use @option{-drive} as well) the ID of a drive.

Could use a mention of the default behavior, but since you didn't do
that anywhere else, not doing so is fine, too.

> +@item read-only
> +Open the node read-only. Guest write attempts will fail.
> +@item cache.direct
> +The host page cache can be avoided with @option{cache.direct=on}. This will
> +attempt to do disk IO directly to the guest's memory. QEMU may still perform an
> +internal copy of the data.
> +@item cache.no-flush
> +In case you don't care about data integrity over host failures, use
> +@option{cache.no-flush=on}. This option tells QEMU that it never needs to write

Just text movement, but that doesn't mean we can improve it: While it's
a matter of test whether to use contractions in official documentations
(some do not (e.g. me), others do; and the state of the qemu man page
reflects this well), I'd definitely rather not use an imperative here.
If people do not care about this, they *may contemplate* using this
option. But we should not tell them to.

> +any data to the disk but can instead keep things in cache. If anything goes
> +wrong, like your host losing power, the disk storage getting disconnected
> +accidentally, etc. your image will most probably be rendered unusable.

Especially since losing integrity of your data is something different
than losing access to your data entirely.

> +@item discard=@var{discard}
> +@var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and controls
> +whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap}) requests are
> +ignored or passed to the filesystem.  Some machine types may not support

Again, just text movement, but the double whitespace after the period
here is inconsistent with the rest.

> +discard requests.
> +@item detect-zeroes=@var{detect-zeroes}
> +@var{detect-zeroes} is "off", "on" or "unmap" and enables the automatic
> +conversion of plain zero writes by the OS to driver specific optimized
> +zero write commands. You may even choose "unmap" if @var{discard} is set
> +to "unmap" to allow a zero write to be converted to an UNMAP operation.

Once more, just text movement, but to be consistent, I'd prefer
@dfn{unmap} here like above.

Max

> +@end table
> +
> +@end table
> +
>  ETEXI
>  
>  DEF("drive", HAS_ARG, QEMU_OPTION_drive,


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

  reply	other threads:[~2016-09-23 17:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23 16:06 [Qemu-devel] [PATCH v2 0/3] Add -blockdev command line option Kevin Wolf
2016-09-23 16:06 ` [Qemu-devel] [PATCH v2 1/3] block: Add '-blockdev' " Kevin Wolf
2016-09-23 16:54   ` Eric Blake
2016-09-23 17:32   ` Max Reitz
2016-09-23 16:06 ` [Qemu-devel] [PATCH v2 2/3] doc: Document generic -blockdev options Kevin Wolf
2016-09-23 17:15   ` Max Reitz [this message]
2016-09-23 16:06 ` [Qemu-devel] [PATCH v2 3/3] doc: Document driver-specific " Kevin Wolf
2016-09-23 17:00   ` Eric Blake
2016-09-23 17:32   ` Max Reitz
2016-09-23 16:14 ` [Qemu-devel] [PATCH v2 0/3] Add -blockdev command line option no-reply

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=1c843f20-a649-91da-67b6-9aa594a23e94@redhat.com \
    --to=mreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@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).