Hey Manu,
On Wed, Dec 07, 2022 at 04:45:38PM +0000, Emmanuel Baccelli via RIOT wrote:
there were some discussions on Matrix which could be good to partially move/summarize here to leave some trace @maribu @miri64 @Kaspar @oleg
thanks for the reminder.
When I recall the last ten years of RIOT development a lot of things come to mind. Let me share some of my thoughts (partly also taken from the discussion on Matrix). I will start with some technical aspects:
Multitasking OS
I think RIOT can claim to be a trailblazer for multi-tasking OS in the domain of constrained-node networks. When we started the consensus was not to use multitasking for most embedded OS, but rather go for an singlethreaded, purely event-driven approach which require various quirks (cf. Contiki Protothreads or TinyOS nesC). Today multitasking can be considered the default paradigm for IoT OS and from the basic architecture, Zephyr or mbed OS follow a similar approach (as far as I know).
Of course, RIOT was not the first multi-tasking OS for MCUs but among comparable candidates, the claim holds true as far as I can tell.
GNRC
The consensus seems to be:
- bad idea: using (too many) threads
- debatable: netapi
- quite good idea: pktbuf
In general, I think it is fair to claim that GNRC has not been a failure but we would design it differently today. When discussing the pros and cons we have to bear in mind that the goal for GNRC was never to be the most efficient or most performant network stack but provide a base for general purpose applications and to enable research and teaching on IoT networking. The fact, that GNRC has been the default network stack in RIOT over the last ~8 years (?) even with other network stacks being available is a good indication for it being useful.
On the other hand, debugging, stabilizing, and maintaining has been a time consuming task. It required a lot of efforts for testing and a lot of dedication by @miri64 (and some others) to get it stable and mature.
APIs
We should talk about the benefits and pains when it comes to developing (stable) APIs like
- sock
- netdev
- SAUL
- peripheral
- timer interfaces (swtimer, utimer, vtimer, xtimer, ztimer…)
Programming languages
In my opinion, RIOT has always been very open to enable different programming and scripting languages on top of the core OS. However, there was certainly a strong lack of (heavy) users for most of the languages (C++, micropython, Javascript…) that eventually let to the fact that many features of these languages remained probably not well supported or missing all together.
The biggest success story in terms of programming languages other than C in RIOT up to date is definitely RUST. I guess @chrysn and @kaspar can provide more input here.
Cheers Oleg
– panic(“mother…”); linux-2.2.16/drivers/block/cpqarray.c