Having a (public) roadmap is very good idea, it guides and organizes efforts over time and also gives indication to existing or potential users about which features which are not currently but might as well be there soon.
I personally would like to see support for Bluetooth/WiFi on widely used hardware platforms. I'm currently working on getting BLE on nRF working so it is a matter of time. I hope that also Alan might steer Espressif into add support for ESP32. LoRaWAN stack would also be interesting. I would also add the current documentation effort as part of the roadmap. I think with a Roadmap laid out it would be possible to create GitHub milestones (major and minor) and organize issues into each, depending on how disruptive the change is. This would help to have for example a 10.x series more or less stable while holding bigger changes towards 11.0 or even 12.0. Just my two cents. Best, Matias On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote: > One of the things that I think we are missing is a Roadmap to guide and > prioritize new feature development. Other RTOS' (like Zephyr) do have > such published roadmaps and are responsive to needs and requests of > users and sponsors. I have even seen web pages where the Zephyr team > has laid out what new features on the roadmap will be available in > future releases. > > While I think it would be essentially impossible for us to manage such a > thing with our loose organiation, I think we should have a roadmap that > identifies the important directions that operating system will take. > > For me, the important thing is to stay relevant and contemporary and not > get lost in some aging niche architecture or toolset. I think that the > best way to predict where NuttX needs to be is to look at the SoCs in > use just above the upper end of the NuttX market. I think over time, > those features will trickle down into embedded systems (albeit with some > twists and modifications for the embedded market). The Cortex-M7 > introduces I-Cache and L1 D-Cache, for example. A few years ago, those > were higher end features not available on MCUs. > > I think that SMP and AMP are key technologies to get us a leg up on > future mutli-core MCUs. KERNEL mode places us in a position to support > MCUs with MMUs. A proper TrustZone model for all ARM parts is needed > too (the multi-core TrustZone model is pretty well in place, but what do > we do with TrustZone on a single CPU?). > > Security, especially IoT security is very important. Some security > topics are addressed by PROTECTED mode. So although PROTECTED and > KERNEL build modes are not commonly used, I believe that they are > important parts of the roadmap. > > Other thoughts? We should collaborate and define a meaningful roadmap > that will keep the OS healthy well into the future. We should publish > that roadmap somewhere so that anyone can see where we are going and can > offer insights for other directions. > > >
