From: Kevin Wolf <kwolf@redhat.com>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: berrange@redhat.com, John Snow <jsnow@redhat.com>,
qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 2/4] block.c: adding bdrv_delete_file
Date: Tue, 3 Sep 2019 12:06:12 +0200 [thread overview]
Message-ID: <20190903100612.GE4582@localhost.localdomain> (raw)
In-Reply-To: <eeb3a0ff-2b95-2285-10e1-ae9bd2c4ba0e@gmail.com>
Am 03.09.2019 um 11:55 hat Daniel Henrique Barboza geschrieben:
>
>
> On 9/3/19 6:22 AM, Kevin Wolf wrote:
> > Am 29.08.2019 um 04:07 hat John Snow geschrieben:
> > >
> > > On 8/7/19 10:21 AM, Daniel Henrique Barboza wrote:
> > > > Using the new 'bdrv_co_delete_file' interface, bdrv_delete_file
> > > > can be used in a way similar of the existing bdrv_create_file to
> > > > to clean up a created file.
> > > >
> > > > The logic is also similar to what is already done in bdrv_create_file:
> > > > a qemu_coroutine is created if needed, a specialized function
> > > > bdrv_delete_co_entry is used to call the bdrv_co_delete_file
> > > > co-routine of the driver, if the driver implements it.
> > > >
> > > > Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> > > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> > > > ---
> > > > block.c | 77 +++++++++++++++++++++++++++++++++++++++++++
> > > > include/block/block.h | 1 +
> > > > 2 files changed, 78 insertions(+)
> > > >
> > > > diff --git a/block.c b/block.c
> > > > index cbd8da5f3b..1e20250627 100644
> > > > --- a/block.c
> > > > +++ b/block.c
> > > > @@ -547,6 +547,83 @@ int bdrv_create_file(const char *filename, QemuOpts *opts, Error **errp)
> > > > return ret;
> > > > }
> > > > +typedef struct DeleteCo {
> > > > + BlockDriver *drv;
> > > > + BlockDriverState *bs;
> > > > + int ret;
> > > > + Error *err;
> > > > +} DeleteCo;
> > > > +
> > > > +static void coroutine_fn bdrv_delete_co_entry(void *opaque)
> > > > +{
> > > > + Error *local_err = NULL;
> > > > + DeleteCo *dco = opaque;
> > > > +
> > > > + assert(dco->bs);
> > > > +
> > > > + dco->ret = dco->drv->bdrv_co_delete_file(dco->bs, &local_err);
> > > > + error_propagate(&dco->err, local_err);
> > > > +}
> > > > +
> > > > +int bdrv_delete_file(const char *filename, Error **errp)
> > > > +{
> > > > + BlockDriver *drv = bdrv_find_protocol(filename, true, NULL);
> > > > + BlockDriverState *bs = bdrv_open(filename, NULL, NULL,
> > > > + BDRV_O_RDWR | BDRV_O_PROTOCOL, NULL);
> > > > + DeleteCo dco = {
> > > > + .drv = drv,
> > > > + .bs = bs,
> > > > + .ret = NOT_DONE,
> > > > + .err = NULL,
> > > > + };
> > > > + Coroutine *co;
> > > > + int ret;
> > > > +
> > > > + if (!drv) {
> > > > + error_setg(errp, "File '%s' has unknown format", filename);
> > > > + ret = -ENOENT;
> > > > + goto out;
> > > > + }
> > > > +
> > > I was going to say that ENOENT is a weird error here, but I see it used
> > > for !drv a few other places in block.c too, alongside EINVAL and
> > > ENOMEDIUM. ENOMEDIUM loks like the most popular.
> > >
> > > > + if (!drv->bdrv_co_delete_file) {
> > > > + error_setg(errp, "Driver '%s' does not support image delete",
> > > > + drv->format_name);
> > > > + ret = -ENOTSUP;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + if (!bs) {
> > > > + error_setg(errp, "Could not open image '%s' for erasing",
> > > > + filename);
> > > > + ret = 1;
> > > Please keep all errors negative (or at least consistent within a function).
> > >
> > >
> > > I'm also wondering if we want a version of delete that doesn't try to
> > > open a file directly -- i.e. a version that exists like this:
> > >
> > > bdrv_co_delete_file(BlockDriverState *bs, Error **errp);
> > >
> > > That simply dispatches based on bs->drv to the correct routine.
> > >
> > > Then, you are free to have bdrv_delete_file handle the open (and let the
> > > opening figure out what driver it needs), and just hand off the bds to
> > > bdrv_co_delete_file.
> > >
> > > I'm not the authority for block.c, though, so maaaybe I'm giving you bad
> > > advice here. Kevin's away on PTO for a bit and gave you advice most
> > > recently, so I might try to gently ask him for more feedback next week.
> > Yes, this was definitely the idea I had in mind when I suggested that
> > bdrv_co_delete_file() should take a BDS.
> >
> > And I think the callers that want to call this function (for failures
> > during image creation) all already have a BDS pointer, so nobody will
> > actually need the additional open.
> >
> > const char *filename only works for the local filesystem (and even then
> > I think not for all filenames) and some URLs, so this is not what we
> > want to have in a public interface to identify an image file.
>
> Hmpf, I understood your idead wrong in the v4 review and ended up
> changing the co_routine (bdrv_co_delete_file) to use the BlockDriverState
> instead of the public interface bdrv_delete_file that will be called inside
> crypto.c.
>
> I'll respin it again with this change. Thanks for clarifying!
Yes, I see that I only really commented on the BlockDriver callback, so
it wasn't very clear what I actually meant. Sorry for that.
Kevin
next prev parent reply other threads:[~2019-09-03 10:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 14:21 [Qemu-devel] [PATCH v5 0/4] delete created files when block_crypto_co_create_opts_luks fails Daniel Henrique Barboza
2019-08-07 14:21 ` [Qemu-devel] [PATCH v5 1/4] block: introducing 'bdrv_co_delete_file' interface Daniel Henrique Barboza
2019-08-07 14:21 ` [Qemu-devel] [PATCH v5 2/4] block.c: adding bdrv_delete_file Daniel Henrique Barboza
2019-08-29 2:07 ` John Snow
2019-09-02 18:05 ` Daniel Henrique Barboza
2019-09-03 9:22 ` Kevin Wolf
2019-09-03 9:55 ` Daniel Henrique Barboza
2019-09-03 10:06 ` Kevin Wolf [this message]
2019-08-07 14:21 ` [Qemu-devel] [PATCH v5 3/4] crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails Daniel Henrique Barboza
2019-08-29 2:10 ` John Snow
2019-09-02 18:26 ` Daniel Henrique Barboza
2019-08-07 14:21 ` [Qemu-devel] [PATCH v5 4/4] qemu-iotests: adding LUKS cleanup for non-UTF8 secret error Daniel Henrique Barboza
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=20190903100612.GE4582@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berrange@redhat.com \
--cc=danielhb413@gmail.com \
--cc=jsnow@redhat.com \
--cc=mreitz@redhat.com \
--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.