From: Alberto Garcia <berto@igalia.com>
To: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Kashyap Chamarthy <kchamart@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>
Subject: Re: [RFC PATCH 0/2] Allow changing bs->file on reopen
Date: Fri, 05 Feb 2021 13:47:00 +0100 [thread overview]
Message-ID: <w51ft2abs1n.fsf@maestria.local.igalia.com> (raw)
In-Reply-To: <20210121105217.GA5466@merkur.fritz.box>
On Thu 21 Jan 2021 11:52:17 AM CET, Kevin Wolf wrote:
>> Hmm, still, removing a filter which want to unshare WRITE even when
>> doesn't have any parents will be a problem anyway, so we'll need a
>> new command to drop filter with a logic like in bdrv_drop_filter in
>> my series.
>>
>> Or, we can introduce multiple reopen.. So that x-blockdev-reopen will
>> take a list of BlockdevOptions, and do all modifications in one
>> transaction. Than we'll be able to drop filter by transactional
>> update of top node child and removing filter child link.
>
> Internally, we already have reopen queues anyway, so it would make
> sense to me to expose them externally and take a list of
> BlockdevOptions. This way we should be able to do even complex
> changes of the graph where adding some edges requires the removal of
> other edges in a single atomic operation.
So you mean changing the signature to something like this?
{ 'command': 'x-blockdev-reopen',
'data': { 'options': ['BlockdevOptions'] } }
It should be easy to make that change, I can have a look.
Berto
next prev parent reply other threads:[~2021-02-05 12:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 13:02 [RFC PATCH 0/2] Allow changing bs->file on reopen Alberto Garcia
2021-01-15 13:02 ` [RFC PATCH 1/2] block: " Alberto Garcia
2021-01-18 10:15 ` Vladimir Sementsov-Ogievskiy
2021-01-19 11:46 ` Alberto Garcia
2021-01-15 13:02 ` [RFC PATCH 2/2] iotests: Update 245 to support replacing files with x-blockdev-reopen Alberto Garcia
2021-01-15 13:31 ` [RFC PATCH 0/2] Allow changing bs->file on reopen Kashyap Chamarthy
2021-01-18 10:22 ` Vladimir Sementsov-Ogievskiy
2021-01-20 13:51 ` Alberto Garcia
2021-01-20 13:55 ` Vladimir Sementsov-Ogievskiy
2021-01-21 10:52 ` Kevin Wolf
2021-02-05 12:47 ` Alberto Garcia [this message]
2021-02-05 15:41 ` Kevin Wolf
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=w51ft2abs1n.fsf@maestria.local.igalia.com \
--to=berto@igalia.com \
--cc=kchamart@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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.