nanocoap: allow to define CoAP resources as XFA #19296

benpicco · 2023-02-21T20:44:34Z

Contribution description

Having to define all CoAP resources in one continuous array is a bit of a hassle.
We have XFA now which is a perfect fit for this kind of thing.

The only caveat is that coap_handle_req() lives in nanocoap.c which is shared by all CoAP users.
By the nature of XFAs, we can't have them garbage collected by the linker as the linker is what brings them into existence.
So I added a new nanocoap_resources pseudo-module that needs to be selected to enable the XFA. This has the advantage that we can use the absence of this module to fall-back to the previous implementation, so existing users are not forced to change their code.

Testing procedure

examples/nanocoap_server still works:

$ aiocoap-client coap://[fe80::7837:fcff:fe7d:1aaf%tapbr0]/.well-known/core
application/link-format content was re-formatted
</sha256>,
</riot/ver>,
</riot/value>,
</riot/board>,
</echo/>,
</.well-known/core>

unmodified tests/pkg_edhoc_c also still works

$ aiocoap-client coap://[fe80::7837:fcff:fe7d:1aaf%tapbr0]/.well-known/core
application/link-format content was re-formatted
</.well-known/core>,
</.well-known/edhoc>

Issues/PRs references

riot-ci · 2023-02-21T21:06:13Z

Murdock results

✔️ PASSED

9495dc4 nanocoap_server: add nanocoap_server_auto_init

Success	Failures	Total	Runtime
6881	0	6882	09m:37s

Artifacts

Documentation preview

maribu

lgtm. I do not like to have two competing mechanisms in place, could we deprecate the non-XFA variant of resource management eventually get rid of the old way to provide resources?

sys/include/net/nanocoap.h

examples/nanocoap_server/coap_handler.c

tests/nanocoap_cli/request_handlers.c

benpicco · 2023-02-21T21:22:26Z

could we deprecate the non-XFA variant of resource management eventually get rid of the old way to provide resources?

Sure, this also still needs some better documentation.
We might also just name the module nanocoap_server if it is going to be the only nanoCoAP server module in the long term.

examples/nanocoap_server/coap_handler.c

chrysn · 2023-02-22T17:05:12Z

I haven't manage to look through this yet, but not finding it on a brief grep: Any chance this would consistently work both on gcoap and nanocoap?

benpicco · 2023-02-22T17:13:15Z

Any chance this would consistently work both on gcoap and nanocoap?

In principle yes, since coap_resource_t is shared among both implementations.
It would require a

static gcoap_listener_t _listener = {
    .resources = coap_resources_xfa,
    .resources_len = XFA_LEN(coap_resource_t, coap_resources_xfa),
};

I added it as cc30b81

benpicco · 2023-02-22T23:33:31Z

The last two commits are a bit more experimental, but they do work.

benpicco · 2023-02-28T19:14:53Z

I changed the name of the module to nanocoap_resources as suggested by @miri64

sys/net/application_layer/nanocoap/sock.c

maribu

Code looks good to me, trusting your testing

benpicco · 2023-04-25T15:00:11Z

bors merge

18620: core: add core_mutex_debug to aid debugging deadlocks r=benpicco a=maribu ### Contribution description Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in on log messages such as [mutex] waiting for thread 1 (pc = 0x800024d) being added whenever `mutex_lock()` blocks. This makes tracing down deadlocks easier. ### Testing procedure Run e.g. ```sh USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test ``` which should provide output such as ``` Welcome to pyterm! Type '/exit' to exit. READY s [mutex] waiting for thread 1 (pc = 0x8000f35) START main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug) Test Application for mutex_cancel / mutex_lock_cancelable ========================================================= Test without cancellation: OK Test early cancellation: OK Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d) OK Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0) OK TEST PASSED ``` ```sh $ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf 0x0800024d /home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51 ``` ### Issues/PRs references Depends on and includes #18619 19296: nanocoap: allow to define CoAP resources as XFA r=benpicco a=benpicco 19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=benpicco a=maribu ### Contribution description GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access. In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning. /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds] 88 | ctx[uart].rx_cb = rx_cb; | ~~~^~~~~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx' 52 | static uart_isr_ctx_t ctx[UART_NUMOF]; | ^~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds] 89 | ctx[uart].arg = arg; | ~~~^~~~~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx' 52 | static uart_isr_ctx_t ctx[UART_NUMOF]; | ^~~ ### Testing procedure The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do. ### Issues/PRs references None 19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu ### Contribution description The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue. ### Testing procedure Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again. ### Issues/PRs references The change was added to #19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed. 19507: cpu/cc26x0_cc13x0: Drop feature cortexm_mpu r=benpicco a=maribu ### Contribution description At least the CC2650 doesn't have an MPU, I assume this is also true for the rest of the family. The CC2652 does have an MPU according to the datasheet. So I keep the feature there in place. ### Testing procedure E.g. ``` make BOARD=cc2650-launchpad -C tests/mpu_noexec_ram flash test ``` fails. (Note: A successful test run would also crash but with a mem manage handler rather than a hardfault due to an invalid instruction on the stack being executed.) It would be nice to also test the same for a `cc2652-launchpad`, for which the MPU should work. ### Issues/PRs references None Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>

bors · 2023-04-25T15:03:15Z

Build failed (retrying...):

Murdock

18620: core: add core_mutex_debug to aid debugging deadlocks r=benpicco a=maribu ### Contribution description Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in on log messages such as [mutex] waiting for thread 1 (pc = 0x800024d) being added whenever `mutex_lock()` blocks. This makes tracing down deadlocks easier. ### Testing procedure Run e.g. ```sh USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test ``` which should provide output such as ``` Welcome to pyterm! Type '/exit' to exit. READY s [mutex] waiting for thread 1 (pc = 0x8000f35) START main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug) Test Application for mutex_cancel / mutex_lock_cancelable ========================================================= Test without cancellation: OK Test early cancellation: OK Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d) OK Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0) OK TEST PASSED ``` ```sh $ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf 0x0800024d /home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51 ``` ### Issues/PRs references Depends on and includes #18619 19296: nanocoap: allow to define CoAP resources as XFA r=benpicco a=benpicco Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>

bors · 2023-04-25T15:04:53Z

This PR was included in a batch that was canceled, it will be automatically retried

maribu · 2023-04-25T15:04:57Z

bors r-

bors · 2023-04-25T15:04:59Z

Canceled.

maribu · 2023-04-25T15:44:49Z

bors merge

bors · 2023-04-25T19:08:23Z

Build succeeded:

benpicco · 2023-04-25T19:14:45Z

Thank you for the review!

benpicco requested review from smlng, leandrolanzieri, aabadie, MichelRottleuthner, fjmolinas, miri64, haukepetersen, PeterKietzmann and cgundogan as code owners February 21, 2023 20:44

benpicco requested a review from chrysn February 21, 2023 20:44

github-actions bot added Area: CoAP Area: Constrained Application Protocol implementations Area: examples Area: Example Applications Area: network Area: Networking Area: sys Area: System Area: tests Area: tests and testing framework labels Feb 21, 2023

benpicco force-pushed the coap_resources_xfa branch from 55ba469 to e7a97fb Compare February 21, 2023 20:53

benpicco requested review from bergzand and kaspar030 February 21, 2023 20:54

benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Feb 21, 2023

maribu reviewed Feb 21, 2023

View reviewed changes

sys/include/net/nanocoap.h Outdated Show resolved Hide resolved

examples/nanocoap_server/coap_handler.c Outdated Show resolved Hide resolved

tests/nanocoap_cli/request_handlers.c Outdated Show resolved Hide resolved

benpicco commented Feb 21, 2023

View reviewed changes

examples/nanocoap_server/coap_handler.c Outdated Show resolved Hide resolved

nanocoap: whitespace fixes

c09ad47

benpicco force-pushed the coap_resources_xfa branch from 3593e19 to 09f471d Compare February 22, 2023 17:03

benpicco force-pushed the coap_resources_xfa branch from 09f471d to 67dc89a Compare February 22, 2023 17:08

examples/nanocoap_server: define CoAP resources as XFA

13aa272

benpicco force-pushed the coap_resources_xfa branch from 17cd97b to 8d9a464 Compare February 28, 2023 19:13

benpicco added 2 commits March 9, 2023 14:09

gcoap: include CoAP resrouces from NANOCOAP_RESOURCE() XFA

cc30b81

examples/nanocoap_server: enable fileserver for large boards

8878945

benpicco force-pushed the coap_resources_xfa branch 3 times, most recently from 0e2e879 to 6caf955 Compare March 10, 2023 00:20

chrysn mentioned this pull request Mar 17, 2023

XFA Gcoap handlers #16785

Open

benpicco commented Mar 20, 2023

View reviewed changes

sys/net/application_layer/nanocoap/sock.c Outdated Show resolved Hide resolved

nanocoap_server: add nanocoap_server_auto_init

9495dc4

benpicco force-pushed the coap_resources_xfa branch from f322d4d to 9495dc4 Compare March 22, 2023 13:43

benpicco requested a review from Teufelchen1 April 24, 2023 14:48

maribu approved these changes Apr 25, 2023

View reviewed changes

bors bot merged commit 46af92d into RIOT-OS:master Apr 25, 2023

benpicco deleted the coap_resources_xfa branch April 25, 2023 19:14

benpicco added this to the Release 2023.07 milestone Aug 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

nanocoap: allow to define CoAP resources as XFA #19296

nanocoap: allow to define CoAP resources as XFA #19296

benpicco commented Feb 21, 2023 •

edited

Loading

riot-ci commented Feb 21, 2023 •

edited

Loading

maribu left a comment

benpicco commented Feb 21, 2023 •

edited

Loading

chrysn commented Feb 22, 2023

benpicco commented Feb 22, 2023 •

edited

Loading

benpicco commented Feb 22, 2023

benpicco commented Feb 28, 2023

maribu left a comment

benpicco commented Apr 25, 2023

bors bot commented Apr 25, 2023

bors bot commented Apr 25, 2023

maribu commented Apr 25, 2023

bors bot commented Apr 25, 2023

maribu commented Apr 25, 2023

bors bot commented Apr 25, 2023

benpicco commented Apr 25, 2023 •

edited

Loading

nanocoap: allow to define CoAP resources as XFA #19296

nanocoap: allow to define CoAP resources as XFA #19296

Conversation

benpicco commented Feb 21, 2023 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

riot-ci commented Feb 21, 2023 • edited Loading

Murdock results

Artifacts

maribu left a comment

Choose a reason for hiding this comment

benpicco commented Feb 21, 2023 • edited Loading

chrysn commented Feb 22, 2023

benpicco commented Feb 22, 2023 • edited Loading

benpicco commented Feb 22, 2023

benpicco commented Feb 28, 2023

maribu left a comment

Choose a reason for hiding this comment

benpicco commented Apr 25, 2023

bors bot commented Apr 25, 2023

bors bot commented Apr 25, 2023

maribu commented Apr 25, 2023

bors bot commented Apr 25, 2023

maribu commented Apr 25, 2023

bors bot commented Apr 25, 2023

benpicco commented Apr 25, 2023 • edited Loading

benpicco commented Feb 21, 2023 •

edited

Loading

riot-ci commented Feb 21, 2023 •

edited

Loading

benpicco commented Feb 21, 2023 •

edited

Loading

benpicco commented Feb 22, 2023 •

edited

Loading

benpicco commented Apr 25, 2023 •

edited

Loading