Skip to content

RIOT Summit roadmap session 2017

Kaspar Schleiser edited this page Oct 21, 2017 · 5 revisions


  1. Agenda Bashing
  2. Documentation/Web page
  3. Power management
  4. Network stack - lower layers
  5. Network stack - upper layers
  6. Software update
  7. Security
  8. Build System
  9. Testing
  10. AOB

Meeting Details


  • Emmanuel Baccelli
  • Ludwig Knüpfer
  • Kaspar Schleiser
  • Vincent Dupont
  • Koen Zandberg
  • Cédric Adjih
  • Alexandre Abadie
  • Robert Hartung
  • Kai Beckmann
  • Matthias Miehl
  • Francisco Javier Acosta Padilla
  • Gaetan Harter
  • Kai Beckmann
  • Frederic Saint-Marcel
  • Michel Rottleuthner
  • Jose Ignacio Alamos
  • Paul Vollebregt
  • Oleg Hahm


  • Oleg

Agenda Bashing

Build system was added to the agenda

Documentation/Web page

Agreement made to put a more prominent link to the virtual machine setup (vagrant) for RIOT development machine on the RIOT web page. Also, the link to the RIOT tutorial should be very prominent on the RIOT web page. This will be part of the (hopefully soon) coming web page revamp.

It was proposed to reduce the points of entry (web page, wiki, API documentation).

Following the advices made in the talk by Eric, it should be documented which QA and security measures (e.g., CI tests, static code analysis, security mailing list) are taken.

It was (once again) discussed how to semi-automatically document the maturity/stability and feature-completeness of for supported boards. The questions regarding the level of details, whether the page should be editable manually, and if it can be derived from doxygen documentation remained open. Agreement made to take the discussion to the mailing list (@kaspar030).

Power management

The current concept is alright, but it's implementation needs work. Two approaches to fix it were made by Robert. UART is identified as one problem, because it is used in diverging contexts. The issue of timers is a topic on its own. It was proposed to integrate a timer GPIO timer selection into the periph API. (don't unterstand this - Kaspar)

Network stack - lower layers

Work ongoing for:

  • BLE
  • Lora
  • TSCH

A paradigm change event handling is on its way.

There is a desire for a error reporting mechanism towards the upper layers of the network stack.

Network stack - upper layers

Short summary of the BLE breakout session.

It was agreed that the sock API should be extended to make it easier to implement nested protocols (e.g., (D)TLS which is stacked on top of UDP).

Software update

This is currently work in progress concerning a standard compliant solution.


The issue of the PRNG was discussed (once again).

It was assessed that we need to make progress here. Some sort of a small mini conference was proposed.

We should try to pull more security people in the discussion.

Proper MPU support is important in this regard.

More static code analysis (like address sanitizers or Coverity) should be integrated into the CI setup.

It was proposed to work on a dedicated RIOT security document.

Build System

Can we fix the current GNU make based build system? Maybe. The most pressing shortcomings have been fixed lately, thus there's a lot less pressure now.


Exercises and tutorial applications should be added to testing, but should be built against a certain RIOT version.

Is the "ready for CI flag" obsolete? No, it has also security implications. Maybe PRs without the flag could be run at a low priority? Maybe static tests could always be run, but on (security wise safe) Travis?


The question was raised whether to try to revive the task force idea, but concluded that we assigned deputies to the various road map areas instead.

People agreed that a periodic developer call (once every two weeks) would be nice. Potentially, with a Jabber scriber instead of direct remote participation via conferencing software. Paco proposed to adopt the MCUboot meeting structure and to take the lead as a moderator. The meeting should not take longer than 15 to 30 minutes max. In general there is a desire to involve the community more.

There is a strong desire to

  • get the STM32 drivers merged
  • unblock the I2C situation. We need to find a general solution to deal with long-blocking PRs/RFCs.
Clone this wiki locally
You can’t perform that action at this time.