Skip to content

doc: clean up roadmap #20126

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.

Sign up for GitHub

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
maribu merged 1 commit into from
Dec 1, 2023
Merged

doc: clean up roadmap #20126

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 22 additions & 44 deletions doc/doxygen/src/roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,95 +8,73 @@ The text and items below are tentative, up for discussion, to be updated by regu
# Network Stack High layers
(contact/steering: [Martine](https://github.com/miri64))

1. ICN stack support clean-up
2. discuss mid- and long-term plans for network stack maintenance & development (GNRC vs other supported stacks)
3. Support for CoAP blockwise transfer, observe. Also see [Ken's](https://github.com/kb2ma) unofficial [CoAP for RIOT](https://github.com/kb2ma/RIOT/wiki/CoAP-Home) page.
4. revisit network time synchronization
- ICN stack support clean-up
- discuss mid- and long-term plans for network stack maintenance & development (GNRC vs other supported stacks)
- revisit network time synchronization



# Network Stack Low layers
(contact/steering: [Peter](https://github.com/PeterKietzmann))
Comment thread
miri64 marked this conversation as resolved.

1. Towards fully open source support of 6LoWPAN over BLE
2. Re-integrate and clean-up 802.15.4 TSCH integration
3. Retransmissions by MAC: finalize and merge `netdev_retrans`
4. Point-to-Point Protocol (PPP): finalize and merge `gnrc_ppp`
- Point-to-Point Protocol (PPP): finalize and merge `gnrc_ppp`



# Power Modes
(contact/steering: [Hauke](https://github.com/haukepetersen))
Comment thread
miri64 marked this conversation as resolved.

1. ~~RFC from \@gebart for arbitrary freq for xtimer~~ done
2. ~~prototype LPM concept from Kaspar, demoed on PLACE-HOLDER hardware. Basic idea is to define unified/simplified layered LP modes that apply to 99% of IoT hardware. More optimized board-specific LPM would~~ prototype done
3. implement PM interface for existing platforms (-> https://github.com/RIOT-OS/RIOT/issues/6802)
4. xtimer use of RTT low-power timer
5. concept to fix shell usage issue while LPM activated
6. integrate generic power management functions in device driver APIs (netdev, SAUL, ...)
7. more advanced LPM concepts:
- potentially get rid of idle thread
- concept to fix shell usage issue while LPM activated
- integrate generic power management functions in device driver APIs (netdev, SAUL, ...)
- more advanced LPM concepts:
- sleeping for short periods (in cases where it is not feasible to switch to the idle thread and back) -> mitigate active waiting



# Peripheral drivers
(contact/steering: [Hauke](https://github.com/haukepetersen))

1. remodeling of the `periph/i2c.h` interface and subsequent adaption/rewrite of all existing implementations (-> https://github.com/RIOT-OS/RIOT/issues/6577)
2. cleanup and unification of low-level timer interfaces (`timer`, `rtt`, `rtc`)
3. introduction of `spi_slave` interface
4. introduction of `i2c_slave` interface
- cleanup and unification of low-level timer interfaces (`timer`, `rtt`, `rtc`)
- introduction of `spi_slave` interface
- introduction of `i2c_slave` interface



# Software Updates
(contact/steering: [Emmanuel](https://github.com/emmanuelsearch))

1. ~~Basic bootloader, flashing and booting one of multiple firmware slots~~ done, see [riotboot](https://github.com/RIOT-OS/RIOT/tree/master/bootloaders/riotboot)
2. ~~Secure firmware update over CoAP compliant with SUIT draft spec [draft-ietf-suit-manifest-03](https://tools.ietf.org/html/draft-ietf-suit-manifest-03)~~ done, see [SUIT update example](https://github.com/RIOT-OS/RIOT/tree/master/examples/suit_update)
3. Update SUIT spec support to comply with [draft-ietf-suit-manifest-04](https://tools.ietf.org/html/draft-ietf-suit-manifest-04)
4. Modularize to provide toolbox supporting other image storing (e.g. support external flash), transport (other than CoAP), crypto (e.g. secure element).
5. riotboot support for architectures other than Cortex-M
- Modularize to provide toolbox supporting other image storing (e.g. support external flash), transport (other than CoAP), crypto (e.g. secure element).
- riotboot support for architectures other than Cortex-M



# Documentation
(contact/steering: [Emmanuel](https://github.com/emmanuelsearch))

1. ~~publish roadmap~~ done
2. ~~Introduce RIOT Developer Memos~~ done, see [RDM0](https://github.com/RIOT-OS/RIOT/tree/master/doc/memos)
3. Write and publish more RDMs
4. revamp RIOT website (see [Web Revamp Task Force](https://github.com/RIOT-OS/RIOT/wiki/Website-Revamp-Task-Force))
- Write and publish more RDMs



# Low-level Hardware Support
(contact/steering: [Alex](https://github.com/aabadie))

1. Improved MIPS support
2. radio support for TI SensorTag
3. radio support for Silab Thunderboard
4. ESP32 support
- radio support for TI SensorTag
- radio support for Silab Thunderboard



# Testing
(contact/steering: [Kaspar](https://github.com/kaspar030))

1. ~~automated unit tests with hardware in the loop (SAMR21 plugged on CI server?)~~ (done, Murdock and Philipp)
2. automated network functionality tests (e.g. RPL + UDP/PING tests through border router, multi-hop) in IoTLAB dev sites?
3. ~~leverage PiFleet more?~~ done, 1. uses PiFleet
4. On-board CI testing in IoT-LAB (as it will provide soon the possibility to add custom nodes)

@maribu maribu Nov 30, 2023

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@MrKevinWeiss and @miri: Could you take a look at what is done already here? Don't the automated release test cover this as well?

@miri64 miri64 Dec 1, 2023

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If you want my feedback earlier, you need to mention @miri64 ;-). @miri got some very angry replies in the past.

And yes, the release test should cover this.

@maribu maribu Dec 1, 2023 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@miri got some very angry replies in the past.

Oopsie 😊

And yes, the release test should cover this.

Thx :-)

- automated network functionality tests (e.g. RPL + UDP/PING tests through border router, multi-hop) in IoTLAB dev sites?



# Security
(contact/steering: [Kaspar](https://github.com/kaspar030))

1. RNG unified (secure, or basic), seeding
2. easy TinyDTLS integration in sock, with CoAP etc.
4. RIOT default configuration = secure configuration (that's our goal/motto)
- RNG unified (secure, or basic), seeding
- RIOT default configuration = secure configuration (that's our goal/motto)


## 802.15.4 link layer security
Expand All @@ -108,7 +86,7 @@ with no guidance on how to (and no practical ways to) use that securely

Goal: Usably secure defaults.

1. Figure out applicability of [RFC9031](https://www.rfc-editor.org/rfc/rfc9031) ("CoJP") to non-6TiSCH scenarios.
2. Implement RFC9031 with any extensions needed for the MACs RIOT has.
3. Provide tools to set up a recommended JRC, and to provision keys between it and the device at flash time.
This may entail extensions to the build process, as CoJP requires per-device secrets.
- Figure out applicability of [RFC9031](https://www.rfc-editor.org/rfc/rfc9031) ("CoJP") to non-6TiSCH scenarios.
- Implement RFC9031 with any extensions needed for the MACs RIOT has.
- Provide tools to set up a recommended JRC, and to provision keys between it and the device at flash time.
This may entail extensions to the build process, as CoJP requires per-device secrets.