Make Nanostack C++ constructor initialise Nanostack #7173
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Nanostack object constructor didn't actually initialise Nanostack. Nanostack initialisation was deferred until an interface was actually attached to the stack, which generally happened at first interface connect. Not normally a problem, unless you're trying to make direct Nanostack setup calls prior to connect - some applications do this, and were relying on ThreadInterface::initialise to do Nanostack initialisation. Unfortunately in 5.9 ThreadInterface::initialise no longer does initialise Nanostack immediately, because the mesh interfaces were aligned and integrated with the Ethernet interfaces, which did initialisation on connect(). Make the Nanostack object constructor initialise Nanostack (as the LWIP constructor does for lwIP), so calling Nanostack::get_instance() is the 5.9 API for Nanostack initialisation. For future work, APIs like ns_file_system_set_root_path should be exposed as methods of Nanostack, so everything happens with a single Nanostack::get_instance().file_system_set_root_path().
juhhei01
approved these changes
Jun 8, 2018
JarkkoPaso
approved these changes
Jun 8, 2018
|
/morph build |
Build : SUCCESSBuild number : 2305 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1927 |
Test : SUCCESSBuild number : 2082 |
cmonr
approved these changes
Jun 11, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Nanostack object constructor didn't actually initialise Nanostack. Nanostack initialisation was deferred until an interface was actually attached to the stack, which generally happened at first interface connect.
Not normally a problem, unless you're trying to make direct Nanostack setup calls prior to connect - some applications do this, and were relying on ThreadInterface::initialise to do Nanostack initialisation.
Unfortunately in 5.9 ThreadInterface::initialise no longer does initialise Nanostack immediately, because the mesh interfaces were aligned and integrated with the Ethernet interfaces, which did initialisation on connect().
Make the Nanostack object constructor initialise Nanostack (as the LWIP constructor does for lwIP), so calling Nanostack::get_instance() is the 5.9 API for Nanostack initialisation.
For future work, APIs like ns_file_system_set_root_path should be exposed as methods of Nanostack, so everything happens with a single Nanostack::get_instance().file_system_set_root_path().
Pull request type