On Fri, Mar 31, 2023 at 6:31 PM Nathan Hartman wrote: > In "[Breaking change] Move nxmutex to sched" there was a more general > discussion about our development priorities: What is most important to > us about NuttX? > > I'm pulling out this part of the discussion to a new thread, to avoid > clogging up the nxmutex discussion... > (..) > On Thu, Mar 30, 2023 at 5:44 PM Gregory Nutt wrote: > > We are creating something uncommon; we are creating an RTOS that let's > > you run POSIX (read Linux ) code while retaining the real time, > > deterministic performance of an RTOS If we sacrifice either the real > > time nature or POSIX compatibility, then we have failed. > > > > We are not building another Linux. We already have a very nice one, > > thank you. > > > > We have had other discussions recently about tradeoffs between POSIX > > compatibility and code size. I don't think that was resolved to > > everyone's satisfaction. > > > > It seems to me that when we have to make trade-offs , we tend to do so > > according to the following three values: > > > > 1. Real time, deterministic behavior, > > 2. Standards compliance, and > > 3. OS Footprint > > > > Based on recent decisions and tradeoffs, I list those in what seems to > > be their decreasing order of importance to the project. Do you agree > > with those values and their importance? If so, should they be enshrined > > somehow? > > > > Some of this is in INVIOLABLES.md. But INVIOLABLES.md mostly addresses > > a lower level set of design values: Modularity, coding style, etc. > > This is a very good summary. I think it describes very well what our > priorities have been until now, I think we should keep the same list > of priorities moving forward, and it might be useful to codify it > somewhere that NuttX is developed with this order of importance > (copying Greg's summary): > > [[[ > 1. Real time, deterministic behavior, > 2. Standards compliance, and > 3. OS Footprint > ]]] > > Regarding (1), as has been said by Greg, myself, and probably others, > the real time deterministic behavior is critical. Without that, I > can't really use NuttX for anything significant. > > Regarding (2), the standards compliance is very helpful because it > makes it possible to write and test most of the non-real-time code on > a PC, where the edit-compile-debug cycle is much faster and more > convenient, and then move working code to embedded. > > Regarding (3), being careful not to grow the OS Flash footprint too > much means that we can make long-lived products and upgrade their > firmware well into the future. This is important for things used in > industry and infrastructure, where product life cycles are measured in > years to decades.
+1 +1 +1 :-) :-) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info