> >> 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?
The most important aspect of NuttX is that it is a real-time OS. It is its "special" feature. If I wanted just a POSIX system, then I would simply use Linux. Linux MPUs and SOMs are very cheap nowadays, and are not lacking in any way compared to MCUs. Being real-time is crucial for many applications. Applications that only NuttX can satisfy, and not Linux (or anything similar). Ignoring this aspect of the OS, simply destroys it. It loses its purpose. And breaks all systems developed till now. Standards compliance is very important, for reasons we all understand and agree on, but it should not interfere with the actual purpose of the OS. Some small deviations were always there, needed to make such a system work, but they were always a "characteristic" of NuttX. Not a "limitation". Please do not get fanatic over the standards. Some things may be defined in standards but they may be totally useless or "stupid" for the actual real-life applications that NuttX is used for. Similarly, some "custom" features may be very well needed. Always be realistic. > 1. Real time, deterministic behavior, > 2. Standards compliance, and > 3. OS Footprint I couldn't agree more. I propose a change in INVIOLABLES.md making the above totally clear. On Fri, Mar 31, 2023 at 7:40 PM Tomek CEDRO <to...@cedro.info> wrote: > 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 >
