Linux bluetooth development
 help / color / mirror / Atom feed
From: "Stotland, Inga" <inga.stotland@intel.com>
To: "Gix, Brian" <brian.gix@intel.com>,
	"michal.lowas-rzechonek@silvair.com" 
	<michal.lowas-rzechonek@silvair.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: mesh: Handling application failures on Create/Join/Import
Date: Tue, 17 Dec 2019 21:11:53 +0000	[thread overview]
Message-ID: <b019f8a18e0cbf814bfeba080407b02ae1490909.camel@intel.com> (raw)
In-Reply-To: <20191217200620.qnbhjevotlxfrwu3@kynes>

Hi Michal, Brian,

On Tue, 2019-12-17 at 21:06 +0100, michal.lowas-rzechonek@silvair.com
wrote:
> On 12/17, Gix, Brian wrote:
> > > Indeed. Would you be willing to accept a patch that changes token
> > > delivery to use JoinComplete call in all cases, and checks that the call
> > > returns successfully?
> > 
> > Maybe...  I need to discuss it with Inga.  How does this relate to
> > Create() though?  There is no JoinComplete() call currently axs a
> > result of Create()...  just the return value from the Create() method.
> > Is your problem that the daemon cannot be sure that the return value
> > (token) from Create() was received?
> 
> Yes, exactly.
> 

As much as I don't like API changes in a released code, this seems to
be a legitimate case for doing so.

So yes, let's change the logic so that all three methods (Join, Create,
and Import) have void return values and the token is delivered in
JoinComplete(). A node is "finalized" only upon successful return of
JoinComplete().

Best regards,
Inga

  reply	other threads:[~2019-12-17 21:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-17 18:43 mesh: Handling application failures on Create/Join/Import Michał Lowas-Rzechonek
2019-12-17 18:47 ` Michał Lowas-Rzechonek
2019-12-17 18:56   ` Gix, Brian
2019-12-17 19:01     ` Gix, Brian
2019-12-17 19:11       ` michal.lowas-rzechonek
2019-12-17 19:18         ` Gix, Brian
2019-12-17 20:06           ` michal.lowas-rzechonek
2019-12-17 21:11             ` Stotland, Inga [this message]
2019-12-17 22:09               ` Gix, Brian

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=b019f8a18e0cbf814bfeba080407b02ae1490909.camel@intel.com \
    --to=inga.stotland@intel.com \
    --cc=brian.gix@intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=michal.lowas-rzechonek@silvair.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox