Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status callbacks #6032

Merged
merged 6 commits into from
Feb 15, 2018
Merged

Status callbacks #6032

merged 6 commits into from
Feb 15, 2018

Conversation

jarlamsa
Copy link
Contributor

@jarlamsa jarlamsa commented Feb 7, 2018

Description

Original PR to a feature branch: #5457
This PR adds cases when disconnect happens without user calling disconnect()
For lwip, if ethernet cable is disconnected
Nanostack 6LoWPAN - if connection to border router / outside is lost
Nanostack Thread - if connection to border router / outside is lost
Nanostack Ethernet - if ethernet cable is disconnected

Status

READY

Migrations

YES

These were discussed in the original PR: #5457
The new commits are not modifying these already discussed changes

In NetworkInterface new APIs:
-attach() for connection status callback registering
-get_connection_status()
-set_blocking()

In PPPCellularInterface:
-connection_status_cb() removed

Related PRs

feature-status-callbacks | #5457

Todos

  • Documentation needs to be updated

Deploy notes

Steps to test or reproduce

@kjbracey
Copy link
Contributor

kjbracey commented Feb 7, 2018

Looking at that, should we squash the entire original branch to 1 commit, as all the steps are review comments?

@jarlamsa
Copy link
Contributor Author

jarlamsa commented Feb 7, 2018

Please review @kjbracey-arm @TeemuKultala @geky @AnttiKauppila @sg- @0xc0170 @mikaleppanen

@jarlamsa
Copy link
Contributor Author

jarlamsa commented Feb 7, 2018

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2018

This targets master, not feature-status-callbacks ?

@kjbracey
Copy link
Contributor

kjbracey commented Feb 7, 2018

Yes, the aim was to land the feature branch on master for 5.8. This is doing that in one step, incorporating implement fixes found during testing.

Do you want to do a three-step process - you rebase the feature branch, then PR for fixes to it, then PR to merge feature to master?

I guess now we know we have a compatibility break, going to feature branch first would give Ublox an opportunity to submit a PR for new binary to that feature-branch.

@kjbracey
Copy link
Contributor

kjbracey commented Feb 7, 2018

Possible immediate workaround for ODIN_W2 - temporary hack to NetworkInterface that makes the new methods non-virtual if target is Odin W2?

Will render the feature non-functional on that board for now.

Copy link
Contributor

@kjbracey kjbracey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Content looks fine to me - just that 1 query.

I'd be inclined to squash all the original feature branch work to 1 commit rather than including all the review changes on master. Not sure what others think.

return;
} else {
memcpy(thread_tasklet_data_ptr->ip, temp_ipv6, 16);
if (memcmp(thread_tasklet_data_ptr->ip, thread_tasklet_data_ptr->link_config.mesh_local_ula_prefix, 8) == 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to re-read the mesh_local_ula prefix too? Is that only set on the initial connect, or is it being updated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, correct, that isn't updated, so need to read and update from the thread_management_configuration. I'll make a commit, I tested it already.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2018

I'd be inclined to squash all the original feature branch work to 1 commit rather than including all the review changes on master. Not sure what others think.

History clean up would be good (if its one commit or multiple but concise and clear) 👍

Will render the feature non-functional on that board for now.

We should avoid this. @jarlamsa How to make it compatible with odin?

cc @ARMmbed/team-ublox

@jarlamsa
Copy link
Contributor Author

jarlamsa commented Feb 7, 2018

How to make it compatible with odin?

Ideal scenario would be that ublox would recompile their driver against this PR and push their recompiled binary to this PR
On our own, I don't think we can make this feature compatible with odin since there are API changes and the driver is currently compiled against old definitions.

@andreaslarssonublox
Copy link

Hi, we will update the driver and hopefully have something tomorrow if everything works as expected.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 8, 2018

Please rebase (mesh was updated recently)

@andreaslarssonublox
Copy link

Hi, I have created a new driver release but could not create a PR/merge towards the jarlamsa:status-callbacks branch so maybe you can merge in the binaries instead?
(Another way might be that I make a PR towards mbed-os master but then there will be problems if this branch is rebased I guess since my release branch is based on top of this?)

Driver release v2.4 rc1:
https://github.com/andreaslarssonublox/mbed/tree/ublox_odin_driver_os_5_v2.4_rc1

The driver release is also dependent on this fix otherwise the TCP connection might hard fault:
https://github.com/andreaslarssonublox/mbed/tree/ublox_fix_missing_init_free_lwip_md5

Note that the current wifi tests are not working for ODIN therefore they were not done. However internal u-blox tests have been run and the wifi example. This will be fixed in a later release.

@jarlamsa
Copy link
Contributor Author

jarlamsa commented Feb 9, 2018

@andreaslarssonublox do you mean these commits?
andreaslarssonublox@0b05180
andreaslarssonublox@c2d478e

Note that the current wifi tests are not working for ODIN therefore they were not done.

What do you mean by this? What is breaking them?

@andreaslarssonublox
Copy link

@jarlamsa Yes, those are the commits.

Yes, the tests-network-wifi test cases were not run since we have not fixed some minor issues to get them to pass. However there is no change in behavior since the version 2.3 of the driver.

Teemu Kultala and others added 2 commits February 9, 2018 12:44
This is the original content of feature-status-callbacks, reviewed in
ARMmbed#5457
@0xc0170
Copy link
Contributor

0xc0170 commented Feb 9, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Feb 9, 2018

Build : SUCCESS

Build number : 1100
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6032/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

*
* @param status_cb The callback for status changes
*/
virtual void attach(mbed::Callback<void(nsapi_event_t, intptr_t)> status_cb);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you document what are the parameters of the callback in input ?

From the signature it looks like it may handle more than just status change otherwise why not just take in a nsapi_connection_status_t as the callback parameter ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some explanation is in nsapi_types.h, with nsapi_event_t. Is that clear enough that you understand it? (I know what it means but that may be because I was in the review meetings).

Agree it should be summarised here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that clear enough that you understand it?

Looking at the documentation and signature; what is unclear for me is whether this status_cb will solely handle status change events or if it will receive other kind of events if nsapi_event_t is updated.

If the parameter of the attach function is not destined to handle events other than connection status change events then the interface is overly complex.

If the callback attached handles more than status events in the future then it is a breaking change: the contract with application code stated in comments would have been broken.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this suffice for the documentation:

    /** Register callback for status reporting
     *  
     *  The specified status callback function will be called on status changes
     *  on the network. The parameters on the callback are the event type and
     *  event-type dependent reason parameter.
     *
     *  @param status_cb The callback for status changes
     */
    virtual void attach(mbed::Callback<void(nsapi_event_t, intptr_t)> status_cb);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent is that new events will be added to nsapi_event_t, and users would be expected to ignore event types they didn't know about. That should be documented. There is one new event type already being plotted.

The use of an enum for a set that may be extended is a little iffy; it seems to be a C++-ism to use them instead of #defines, despite that. Precedent has already been set by nsapi_error and nsapi_socket_option_t, which are gradually being extended.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pan- Are you happy with the proposed change in my comment or does it need some refinement?

Copy link
Contributor

@0xc0170 0xc0170 Feb 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good (better than previous version) to me

@mbed-ci
Copy link

mbed-ci commented Feb 9, 2018

@mbed-ci
Copy link

mbed-ci commented Feb 9, 2018

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 12, 2018

/morph build

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 12, 2018

@AnotherButler New API

@mbed-ci
Copy link

mbed-ci commented Feb 12, 2018

Build : SUCCESS

Build number : 1108
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6032/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

@mbed-ci
Copy link

mbed-ci commented Feb 12, 2018

@mbed-ci
Copy link

mbed-ci commented Feb 12, 2018

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 12, 2018

/morph export-build

@mbed-ci
Copy link

mbed-ci commented Feb 12, 2018

@cmonr
Copy link
Contributor

cmonr commented Feb 12, 2018

@jarlamsa Does this PR effectively replace the ARMmbed:feature-status-callbacks branch? Also, will this PR need to be squashed before merging in?

@jarlamsa
Copy link
Contributor Author

jarlamsa commented Feb 13, 2018

@cmonr Yes, this contains all the original changes from ARMmbed:feature-status-callbacks branch. Not sure about squashing though, 2 cherry-picked commits are coming from ublox, and I would like those to be separate commits, 2 commits on top of that.

And if you refer to the squashing discussion earlier, that has already been done.

@kjbracey
Copy link
Contributor

@VeijoPesonen is preparing handbook documentation - please link that PR to here when created.

@VeijoPesonen
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants