All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Nir Soffer <nirsof@gmail.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>, Ala Hino <ahino@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U
Date: Tue, 9 Jan 2018 14:24:25 +0800	[thread overview]
Message-ID: <20180109062425.GA18346@lemon.usersys.redhat.com> (raw)
In-Reply-To: <20180108175729.GI8052@localhost.localdomain>

On Mon, 01/08 18:57, Kevin Wolf wrote:
> I'm not sure if going back to the old behaviour for a while now would be
> helpful, you'd just end up with an even more confusing set of qemu
> versions, for example:
> 
>     <= 2.9          - works without a warning
>     2.10 and 2.11   - errors out
>     2.12            - prints a warning, but works
>     >= 2.13         - errors out again

What I had in mind is settle on warning for good. QEMU (including qemu-img) is a
low level tool that can be used in many ways that it isn't supposed to, this one
is not more harmful than others (e.g. "qemu-img snapshot ..." on iscsi:// qcow2
image) we allow siliently.

I know this is debatable but I think the #1 purpose of image locking is to
prevent data corruption; #2 IMO is to reduce confusion and misinformation.
While inconsistent output of "qemu-img info" is misinformation, it not working
as before is actually confusion. Though the current behavior is indeed ideal,
the proposed patch is a bit more pragmatical.

Fam

  reply	other threads:[~2018-01-09  6:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-05  6:55 [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U Fam Zheng
2018-01-05  6:55 ` [Qemu-devel] [PATCH 1/2] qemu-img: Move img_open error reporting to callers Fam Zheng
2018-01-05 16:03   ` Eric Blake
2018-01-05  6:55 ` [Qemu-devel] [PATCH 2/2] qemu-img: info: try -U automatically Fam Zheng
2018-01-05 16:08   ` Eric Blake
2018-01-08 14:41 ` [Qemu-devel] [PATCH 0/2] qemu-img: Let "info" warn and go ahead without -U Kevin Wolf
2018-01-08 17:07   ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-01-08 17:57     ` Kevin Wolf
2018-01-09  6:24       ` Fam Zheng [this message]
2018-01-09  9:58         ` Kevin Wolf
2018-01-09 19:58           ` Ala Hino
2018-01-09 20:11             ` Eric Blake
2018-01-09 20:29               ` Ala Hino
2018-01-10 12:51       ` Daniel P. Berrange
2018-01-10 12:49   ` [Qemu-devel] " Daniel P. Berrange
2018-01-10 14:07     ` Kevin Wolf
2018-01-10 14:13       ` Daniel P. Berrange
2018-01-10 14:03   ` Kashyap Chamarthy
2018-01-10 16:43     ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-01-11  9:26       ` Kashyap Chamarthy

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=20180109062425.GA18346@lemon.usersys.redhat.com \
    --to=famz@redhat.com \
    --cc=ahino@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nirsof@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.