Add custom transport and storage in SUIT

[donsez]

Description

Firmware update can be operated over protocols than CoAP and VFS.

For instance, additional transport can be HTTP, FTP, RS485, CAN ...

SUIT framework should be extensible with custom protocols for transport and probably storage.

Useful links

This patch gives a possible extension of SUIT for a custom transport https://github.com/thingsat/RIOT/commit/9a0f41733b35cd7df7b4fad9a9fb167fe9ee067c

The 2 functions in have to be implemented and the makefile must contain the following lines

USEMODULE += riotboot
USEMODULE += suit suit_storage_flashwrite

# =====================================================================
# Module suit_transport_custom is a PSEUDO module
USEMODULE += suit_transport_custom
# Custom protocol for transport
CFLAGS += -DSUIT_TRANSPORT_CUSTOM_ROOTDIR=\"can://\"
# ---------------------------------------------------------------------

[chrysn]

Somewhat related, there is https://github.com/RIOT-OS/RIOT/pull/19601 in which the application can receive the manifest however it likes it and places it in the manifest buffer.

Do you envision this for the manifest or also for files referenced in the manifest by URI? If the latter, is anything about this SUIT specific? If not, it may make sense to have a "get data as described from a URI" mechanism, which SUIT should use and into which modules can hook.

The custom CAN transport could then be implemented as an external module and register for "can://" URIs. I don't think we'd want a "custom" module, more an entry point into which modules (including out-of-tree modules) can hook.

[maribu]

For instance, additional transport can be HTTP, FTP, RS485, CAN ...

I fully agree with that.

SUIT framework should be extensible with custom protocols for transport and probably storage.

But I disagree with that :sweat_smile:

E.g. if users A and B want to use UART for SUIT updates, I see little reason to not just join effort and upstream a UART transport for SUIT updates. To me, the implementation space of a transport is not so large that it would allow enough fine-tuning of the involved trade-offs to justify a rewrite of a SUIT transport. So user B would likely just want to reuse the code of user A for the UART transport of SUIT updates.

Would you consider upstreaming the CAN transport for SUIT updates instead?

Also note that SUIT internals are subject to change. An upstream CAN interface however would be part of a public API that we would try to keep stable and only change in backward compatible manner. With an upstream CAN transport, changes of SUIT internals would only be merged if the upstream SUIT transports (including the CAN transport) would be updated to match the new internal APIs. So long term, maintenance effort is lower when upstreaming :wink: