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... For context, with my replies below: On Thu, Mar 30, 2023 at 5:44 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > >> I have mixed feelings myself and hope that we get some consensus through > >> dialog. One one hand, it is important to stay faithful to documented > >> standard and undocumented conventions for the use the a POSIX/Unix > >> systems. But on the other hand, unlike other OSs that strive toward > >> standard conformance, we are an RTOS and must satisfy certain > >> requirements for deterministic, real time behavior. > >> > >> What do you all think? > > > > My opinion is that we have to respect the requirements for deterministic > > real-time behavior, even though that implies the addition of certain > > non-standard interfaces. Otherwise we lose our identity as a real time > > operating system and the applications I am doing with NuttX (and I'm sure > > many other people) will not be possible. > > > > That said, I also very much like that NuttX strives for standards > > conformance. For me, this means that most non-real-time code can be > > developed and tested on a PC with a faster code-compile-debug cycle than > > embedded and then moved over to embedded when it's ready. This has been a > > huge productivity boost for me (and I'm sure, once again, for many other > > people). > > > > How, then, do we satisfy both needs? > > > > I think the answer is that as long as standard functions behave like the > > standards and practices expect, and deviations from the standards use > > identifiers that do not collide with the standards, both needs are > > satisfied well. Applications that do not utilize our real time "extensions" > > will not notice the difference, and applications that do utilize them will > > meet real time requirements as needed. > > > > I think that in large part we are already doing exactly that, so there > > isn't really a problem that needs fixing here. > > > > I don't know the details of this specific PR yet, so I am just giving my > > opinion about the premise of NuttX in general. > > Well said. > > 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. Cheers, Nathan
