From: Kevin Wolf <kwolf@redhat.com>
To: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
Amar Tumballi <atumball@redhat.com>,
Mike Christie <mchristi@redhat.com>,
Prasanna Kalever <pkalever@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Xiubo Li <xiubli@redhat.com>,
Fam Zheng <fam@euphon.net>, stefanha <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility
Date: Mon, 11 Mar 2019 12:06:31 +0100 [thread overview]
Message-ID: <20190311110631.GC7899@localhost.localdomain> (raw)
In-Reply-To: <20190309014648.GA28010@byw>
Am 09.03.2019 um 02:46 hat Yaowei Bai geschrieben:
> Thanks for explaining the background. It comes to my mind that actually we
> talked about these two cases with Fam a bit long time ago and decided to
> support both these two cases. The reason why we implement case2 first is
> currently we care more about exporting new opened images and it's a bit
> more convenient, exporting from a VM or QMP can be added in the later
> release. Do you think it's reasonable/acceptable that we support both
> cases and use case2 for normal new opened images and case1 for the
> circumstances you mention above?
I would like to avoid a second code path because it comes with a
maintenance cost.
Experience also tells that adding a new way to parse option strings will
come back at us later because it we must always maintain compatibility
with yet another format.
So I would prefer not doing this and just passing command line options
to qemu-tcmu, which can reuse the already existing code paths.
Kevin
next prev parent reply other threads:[~2019-03-11 11:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-21 10:16 [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility Yaowei Bai
2018-12-26 7:59 ` no-reply
2018-12-26 8:19 ` no-reply
2019-01-02 1:53 ` Yaowei Bai
2019-03-06 21:56 ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-03-07 8:20 ` Yaowei Bai
2019-03-07 8:44 ` Yaowei Bai
2019-03-07 11:25 ` Kevin Wolf
2019-03-08 7:22 ` Yaowei Bai
2019-03-08 10:08 ` Kevin Wolf
2019-03-09 1:46 ` Yaowei Bai
2019-03-11 11:06 ` Kevin Wolf [this message]
2019-03-12 2:18 ` Fam Zheng
2019-03-07 10:22 ` Stefan Hajnoczi
2019-03-07 10:34 ` Kevin Wolf
2019-03-11 9:55 ` Stefan Hajnoczi
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=20190311110631.GC7899@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=atumball@redhat.com \
--cc=baiyaowei@cmss.chinamobile.com \
--cc=fam@euphon.net \
--cc=mchristi@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pkalever@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiubli@redhat.com \
/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.