All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bandan Das <bsd@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
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 12:42:55 -0400	[thread overview]
Message-ID: <jpgef7d746o.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <CAFEAcA9sx64kcz=wOqeBwGg0YJc-xO-K5yNkoSC8uuCqNF_FYA@mail.gmail.com> (Peter Maydell's message of "Mon, 11 Mar 2019 16:25:05 +0000")

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 11 Mar 2019 at 16:14, Bandan Das <bsd@redhat.com> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > At the moment PARTIAL_DELETE is "ALL_DELETE | READ_ONLY", which
>> > doesn't seem like it makes much sense.
>> >
>>
>> Sorry, can you please clarify what doesn't make sense ?
>
> Generally, if you have multiple bits X, Y in a return
> value, they should be independent. Sometimes we define
> a convenience value Z that's X | Y, but then Z should
> have a name that indicates that it's really doing both
> X and Y (for instance often a READWRITE constant will
> be READ | WRITE). In this case, I don't see why
> PARTIAL_DELETE would be a sensible name to indicate
> "both ALL_DELETE and also READ_ONLY" -- if we only
> partially did a delete why do we set the ALL_DELETE bit ?
>

Because during a recursive call, we were able to successfully
delete objects(s) for the previous call but for "this"
set of objects, it failed which is supposed to return a
partial_delete back.

Does simply "DELETE" instead of "ALL_DELETE" seem less
confusing ? I definitely want to keep PARTIAL_DELETE the
way it is simply because it's easier to refer back
to the spec that way.

> It might be useful to take a step back -- what are
> the different possible outcomes from this function that
> we need to distinguish, and when should we be returning
> which outcome?
>
> thanks
> -- PMM

  reply	other threads:[~2019-03-11 16:52 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 [this message]
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
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=jpgef7d746o.fsf@linux.bootlegged.copy \
    --to=bsd@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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.