1
0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00

Merge pull request #20126 from maribu/roadmap/cleanup

doc: clean up roadmap
This commit is contained in:
Marian Buschsieweke 2023-12-01 18:06:54 +00:00 committed by GitHub
commit 550fef51ac
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -8,34 +8,25 @@ 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))
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))
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
@ -43,60 +34,47 @@ The text and items below are tentative, up for discussion, to be updated by regu
# 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)
- 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
@ -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.