On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: > 1) More opinionated documentation > a) In particular clear instructions: > – where to get compilers for C/C++ > – how to setup project with an application outside of nuttx, and clear > [apps], [libs], [board], [nuttx] structure > – how to set up your own board > These questions are recurring. They were asked on the mailing list recently > again. They are basic things and they should be the second page of > documentation. > b) Typical policy for documentation is that when people ask, the answer > should be put to documentation and the link sent back as an answer. > c) Table of supported features on different platforms and boards, as > discussed recently. For people who want to use NuttX to feel safe and know > how much they need to contribute to make their project work.
Completely agree on the above. I would add that when people add a new board they document it following a set of guidelines (maybe based on a template). Also, new features or breaking changes should be accompanied by documentation changes. Distributing the load on maintaining the documentation IMHO is the way to keep it updated. > 2) Package management > Database where people can submit whatever they want, as long as it works > and they are willing to maintain it. > Description on what such packages need to fulfill to work with NuttX. Some > simple command line tool to inject packages to NuttX projects. On my "NuttX workspace manager" (https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this mechanism that allows you to simply drop a directory containing an app inside an "extra_apps" directory. This works by having a symlink from apps/external point to this directory, where NuttX looks for external apps. The trick is to have a Make.defs recursively including Make.defs from subdirectories and a Makefile including "Directory.mk". This are the files that are placed inside extra_apps/: https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps. If external/ would already have this set up, it would indeed be a matter of dropping an app there. Furthermore, I personally like to use submodules but even if you simply clone or download a git repo containing just the app, you wouldn't need a central database of apps, just a git repo for each app. If some sort of "central repository" is desired, a special github organization could be used to collect contributed apps. I have a similar mechanism for OS level code, which is compiled as if it were a subdirectory of nuttx/. Best, Matias > Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao < > xiaoxiang781...@gmail.com>: > > > I would see the automation test on the roadmap, thanks. > > > > > -----Original Message----- > > > From: Matias N. <mat...@imap.cc> > > > Sent: Wednesday, August 5, 2020 4:59 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: Roadmap? > > > > > > 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. > > > > > > > > > > > > > > > > >
