pkg/libcoap: Add in libcoap CoAP library support

[mrdeep1]

Contribution description

Adds in support for using the libcoap CoAP library with version 4.3.4, as per https://github.com/obgm/libcoap with documentation at https://libcoap.net/doc/reference/develop/ .

pkg/libcoap contains the information for the libcoap library to be included and built as appropriate.
examples/libcoap-client provides an example CoAP client.
examples/libcoap-server provides an example CoAP server.
pkg/Kconfig updated to include libcoap.

Testing procedure

test/pkg/libcoap provided which does a loop-back test with libcoap client logic sending request to libcoap server logic and sanity checks the response.

Issues/PRs references

None, other than adding in new functionality.

[JKRhb]

Just a couple of minor suggestions below to get rid of the warnings.

[riot-ci]

Murdock results

✔️ PASSED

84938e4 pkg/libcoap: Add in libcoap CoAP library support

Success	Failures	Total	Runtime
10255	0	10255	16m:54s

Artifacts

• Documentation preview

[mrdeep1]

Is there anything I need to do here to progress this?

[miri64]

@chrysn could you maybe have a look?

[mrdeep1]

I guess I do not understand why the Murdock test build failed for libcoap - msb-430 is definitely defined in tests/pkg/libcoap/Makefile.ci as a BOARD_INSUFFICIENT_MEMORY entry. It appears that size_t in this case is only 2 bytes wide.

[maribu]

This is correct behavior. The BOARD_INSUFFICIENT_MEMORY is used to flag boards that have too little RAM and/or flash for the linking step to succeed. Hence, the CI will do all compilation steps (to still confirm that the code is otherwise valid and portable C code), but skip the final linking step.

We do have two platforms where size_t is 16 bits wide: AVR and MSP430.

Note that size_t is defined to be able to hold any array index for an in-memory C array. So it may even not be possible to cast any pointer to size_t and back without loosing information, as the address space may be larger than anything that can be stored in RAM in a contiguous fashion.

Hence, size_t is not a suitable type for lengths of files written to e.g. SD cards and transferred over network e.g. using CoAP blockwise transfers.

But given that this bug is likely upstream, you could just add FEATURES_REQUIRED_ANY += arch_32bit|arch_64bit to the Makefile.dep of the package and prevent it from being compiled on our 8 bit and 16 bit boards.

[mrdeep1]

Thanks for the information, It looks like only a compile issue in one place, which I will get fixed shortly.

[maribu]

I only took a quick peek, but this looks good to me. @chrysn might be interested in this, as this would also provide an alternative implementation of OSCORE.

One thing: Most (if not all) of the KConfig parts can be dropped now, (see https://forum.riot-os.org/t/last-chance-for-kconfig-dependency-modelling/4068 for details). Selection of modules and packages and the dependency resolution via KConfig has been removed from upstream; but you can still use KConfig to expose configuration knobs (such as buffer sizes, ports to listen on, etc.).

I can take an in-depth look tomorrow, if you think this is ready for review? Would be cool to get this back in :)

[mrdeep1]

I can take an in-depth look tomorrow, if you think this is ready for review?

I have just found an OSCORE issue that needs to get fixed. I will fix this and have everything pushed for Monday.

Most (if not all) of the KConfig parts can be dropped now

I will look at doing this, probably not by Monday though.

[mrdeep1]

I have just found an OSCORE issue that needs to get fixed. I will fix this and have everything pushed for Monday.

Just pushed the fix. Do you want all these commits squashed?

[maribu]

Just pushed the fix. Do you want all these commits squashed?

Do as you prefer. Some other maintainers are a bit picky about when to squash, but I only look at the diff to upstream (or to when I last checked). So as long as only I am reviewing, you can squash (or not squash) during the review as works best for you.

[mrdeep1]

@maribu I have just pushed libcoap v4.3.5rc1 for review.

I have left in the Kconfig stuff for now - certainly users can just modify app.config to get the same results for configuring things.