Skip to content

Mesh-api setters for eui64 and pskd #6025

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

Merged
merged 1 commit into from
Feb 8, 2018

Conversation

kseverinkangas-zg
Copy link

Notes:

Description

New setters for mesh-api to be used by the Thread network.
Needed by customers when deploying devices for commissioning.

Status

IN DEVELOPMENT

Migrations

NO

Related PRs

Todos

Deploy notes

Steps to test or reproduce

@kseverinkangas-zg
Copy link
Author

@mikter @artokin

@kseverinkangas-zg kseverinkangas-zg force-pushed the thread_api_adds branch 4 times, most recently from 10eab57 to 1f605ad Compare February 6, 2018 16:00
Copy link

@mikter mikter left a comment

Choose a reason for hiding this comment

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

ok

@mikter
Copy link

mikter commented Feb 7, 2018

@kjbracey-arm please review

* \return MESH_ERROR_NONE on success.
* \return MESH_ERROR_PARAM in case of illegal parameters.
* */
mesh_error_t device_eui64_set(uint8_t *eui64);
Copy link
Contributor

Choose a reason for hiding this comment

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

Needs to be a const pointer. Don't see the point of an error return, if it's just a null check. How can an eui64 be invalid? I guess you could fault multicast ones?

Copy link
Author

Choose a reason for hiding this comment

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

Giving NULL is the only case of an error. This is an application api, so even a simple NULL check should be done? Could be done with assert?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm just generally very down on spending code space specifically on NULL checks in APIs. If someone somehow does it, it'll crash. There are lots of other invalid things - pointers to uninitialised memory, pointers to already-freed blocks, pointers outside RAM, multicast addresses... You can't totally protect people from themselves.

With the error test, you'll return the error, and they just won't bother checking the return code anyway...

Given that the existing calls in this API don't bother with NULL checks, I don't see a reason to start now.

Anyway, minor style nit - not really that bothered. The code-in-assert thing below is critical though.

@@ -278,14 +278,10 @@ void thread_tasklet_configure_and_connect_to_network(void)

// PSKd
const char PSKd[] = MBED_CONF_MBED_MESH_API_THREAD_PSKD;
MBED_ASSERT(sizeof(PSKd) > 5 && sizeof(PSKd) < 33);
if(device_configuration.PSKd_len==0) {
MBED_ASSERT(!thread_tasklet_device_pskd_set(PSKd));
Copy link
Contributor

Choose a reason for hiding this comment

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

You can't put code in an assert - it won't be called if a release build.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2018

@karsev Do you want to rebase to clean the log before we trigger tests (possibly squash to one commit ? ) ?

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 8, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Feb 8, 2018

Build : SUCCESS

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

Triggering tests

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

@mbed-ci
Copy link

mbed-ci commented Feb 8, 2018

@mbed-ci
Copy link

mbed-ci commented Feb 8, 2018

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.

5 participants