[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility
From: |
Fam Zheng |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility |
Date: |
Tue, 12 Mar 2019 10:18:11 +0800 |
> On Mar 11, 2019, at 19:06, Kevin Wolf <address@hidden> wrote:
>
> 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.
If the rule is that cfgstr strictly follows -blockdev syntax and the parsing
code is mostly shared, it shouldn’t be a problem, right? I suppose this will
limit the expressiveness of cfgstr but might be a reasonable tradeoff between
implementation complexity, user friendliness and interface consistency.
Another possibility is to use json: format in cfgstr for anything more complex
than a single -blockdev.
>
> So I would prefer not doing this and just passing command line options
> to qemu-tcmu, which can reuse the already existing code paths.
I think the effect of not supporting adding new blockdev from cfgstr is that we
have to resort to QMP to allow hot-adding targets. It’s not necessarily bad,
though I’m not sure hwo that aligns with Yaowei’s development plan.
Fam
>
> Kevin
>
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Kevin Wolf, 2019/03/06
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Yaowei Bai, 2019/03/07
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Yaowei Bai, 2019/03/07
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Kevin Wolf, 2019/03/07
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Yaowei Bai, 2019/03/08
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Kevin Wolf, 2019/03/08
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Yaowei Bai, 2019/03/08
- Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Kevin Wolf, 2019/03/11
- Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility,
Fam Zheng <=
- Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility, Kevin Wolf, 2019/03/12
- Re: [Qemu-block] [Qemu-devel] [PATCH] tcmu: Introduce qemu-tcmu utility, Fam Zheng, 2019/03/13
Re: [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility, Stefan Hajnoczi, 2019/03/07