All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Bandan Das <bsd@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] usb-mtp: fix return status of delete
Date: Mon, 11 Mar 2019 18:56:51 +0000	[thread overview]
Message-ID: <CAFEAcA_wDgYooMLotS-SmASWjRxVhTzn6eeiDgH-zVfu3=v+xA@mail.gmail.com> (raw)
In-Reply-To: <jpga7i1uvr6.fsf@linux.bootlegged.copy>

On Mon, 11 Mar 2019 at 18:11, Bandan Das <bsd@redhat.com> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
> > Looking at the code, we seem to have:
> >  * for any particular node, either we can delete it
> >    or we can't
> >  * we also iterate through each child node recursively
> >
> > So we have to combine together the "deleted this"
> > and "failed to delete this" information for the whole tree.
> > In which conditions should we end up with which RES_*
> > result code? It seems plausible that we want RES_OK
> > only if every deletion attempt in the tree succeeded.
> > But what about the others? Is it supposed to be
> > RES_PARTIAL_DELETE if some deletions succeeded and
> > some failed, and RES_STORE_READ_ONLY if every single
> > deletion failed ?
> >
> Ok, this is easier. Now, I know what you are referring to
> instead of guessing what and how I should be explainng.
>
> What you said is essentially correct. When deleting a
> single object that's a file, the return value would either
> be OK or STORE_READ_ONLY.
>
> When deleting an object which is a folder, Qemu goes through
> its contents. If it succeeds in deleting all the content objects,
> the result is success. If one or some objects couldn't be deleted for
> whatever reason, the result is RES_PARTIAL_DELETE and if none
> of the objects could be deleted, Qemu returns a READ_ONLY.
>
> In usb_mtp_object_delete(), based on the return value of this
> function, we set s->result appropriately.

OK. So we can do this with a return value where the
two relevant bits indicate:
 * bit 0: We had at least one successful deletion
 * bit 1: We had at least one failed deletion

and then the correct RES value is:
 * only bit 0 set: READ_ONLY
 * only bit 1 set: OK
 * both bits set: PARTIAL_DELETE
 * neither bit set: can't happen

This is what your patch does, I think, but you've named
the "at least one deletion succeeded" bit "ALL_DELETE"
(even though it can be set in a return value where not
all of the deletions succeeded) and the "at least one
deletion failed" bit "READ_ONLY" (even though it can
be set in a return value where some deletions succeeded),
which is what I found confusing.

I think the code would be easier to understand if we:
 * picked clearer names for the bits, like
   DELETE_SUCCESS and DELETE_FAILURE
 * had a comment explaining what the return value
   of the function means, something like:

/*
 * Delete the object @o and all its children. In the
 * return value, the DELETE_SUCCESS bit is set if at
 * least one of the deletions succeeded, and the
 * DELETE_FAILURE bit is set if at least one of the
 * deletions failed. If the tree of objects was only
 * partially deleted then both bits will be set.
 */

But really the second of these is the more important:
slightly confusing naming is OK if there is a good
comment explaining what is going on (and my suggested
bit flag names don't really stand on their own without
any explanation either). So if you strongly prefer your names
for the bits that's ok, but please do add a comment,
either at the top of the function or documenting
the meaning of the enum values.

thanks
-- PMM

  reply	other threads:[~2019-03-11 19:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-07  9:54 [Qemu-devel] [PULL 0/4] Usb 20190307 patches Gerd Hoffmann
2019-03-07  9:54 ` [Qemu-devel] [PULL 1/4] usb-mtp: return incomplete transfer on a lstat failure Gerd Hoffmann
2019-03-07  9:54 ` [Qemu-devel] [PULL 2/4] usb-mtp: fix some usb_mtp_write_data return paths Gerd Hoffmann
2019-03-08 17:37   ` Peter Maydell
2019-03-08 19:39     ` Bandan Das
2019-03-07  9:54 ` [Qemu-devel] [PULL 3/4] usb-mtp: prevent null dereference while deleting objects Gerd Hoffmann
2019-03-08 17:06   ` Peter Maydell
2019-03-08 19:46     ` Bandan Das
2019-03-08 22:14       ` [Qemu-devel] [PATCH] usb-mtp: fix return status of delete Bandan Das
2019-03-09 14:13         ` Peter Maydell
2019-03-11 16:14           ` Bandan Das
2019-03-11 16:25             ` Peter Maydell
2019-03-11 16:42               ` Bandan Das
2019-03-11 17:18                 ` Peter Maydell
2019-03-11 17:39                   ` Bandan Das
2019-03-11 17:55                     ` Peter Maydell
2019-03-11 18:11                       ` Bandan Das
2019-03-11 18:56                         ` Peter Maydell [this message]
2019-03-11 23:02                           ` Bandan Das
2019-03-09 14:08       ` [Qemu-devel] [PULL 3/4] usb-mtp: prevent null dereference while deleting objects Peter Maydell
2019-03-07  9:54 ` [Qemu-devel] [PULL 4/4] Introduce new "no_guest_reset" parameter for usb-host device Gerd Hoffmann
2019-03-07 15:21 ` [Qemu-devel] [PULL 0/4] Usb 20190307 patches Peter Maydell

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='CAFEAcA_wDgYooMLotS-SmASWjRxVhTzn6eeiDgH-zVfu3=v+xA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=bsd@redhat.com \
    --cc=kraxel@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.