Exactly!!! If we remove all non-POSIX features and remove all chips that doesn't have MMU, NuttX will run only in 3 or 4 boards.
Is this the direction we want to go? BR, Alan On Thursday, November 20, 2025, raiden00pl <[email protected]> wrote: > TBH, I don't understand these -1 votes... > > NuttX isn't fully POSIX-compliant and never will be, unless we > want to get rid of 80% of the supported targets. Full POSIX compliance > requires an MMU, for example, for proper mmap() implementation. > You can't support "deeply-embedded environments" (quote from doc) and > full POSIX at the same time. This is an obvious contradiction. > POSIX profiles (PSE) improve this somewhat, but an MMU is still required > for full compatibility (mmap issue). > > So what about the features currently present in NuttX that are obviously > not POSIX-compliant? Like everything in `menuconfig DISABLE_OS_API`. > Even the NuttX documentation indirectly states from the very beginning that > NuttX is NOT fully POSIX because it doesn't support fork() which is > required > by the POSIX base specification. > > czw., 20 lis 2025 o 19:41 Tomek CEDRO <[email protected]> napisał(a): > > > -1 from me as per this vote too sorry. > > > > I am sure there are other ways to accomplish that goal. > > > > We do not want to communicate officially in any way that we are "NOT > > POSIX Compliant" on purpose when we clearly state in many places > > "strict POSIX and ANSI compliance" including the Inviolables. That > > will make us incoherent and self-contradictory. > > > > As in my previous response, trimming down the firmware in extreme > > cases can be achieved by removing unused functionalities, at the > > individual responsibility of the developer. I know there may be use > > cases for that, and people still want to use NuttX not the other RTOS, > > which is important. > > > > My proposition is to clearly mark all POSIX functionalities, that are > > enabled and available by default, and when any of them is removed then > > final solution is not POSIX compliant (may be not even used this is up > > to the firmware developer) but necessary to accomplish the task. This > > provides a choice for trimming down the firmware image but sticks to > > POSIX/ANSI by default. > > > > This way we stick to POSIX/ANSI compliance by default. We have clear > > identification of POSIX / PE51 parts. We allow trimming down the final > > firmware in known range of POSIX / PE51 or beyond. > > > > What do you think? :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > On Thu, Nov 20, 2025 at 7:16 PM Gregory Nutt <[email protected]> > wrote: > > > > > > -1 > > > > > > Bad idea. Destroys the core value proposition for the OS. > > > ________________________________ > > > From: Alan C. Assis <[email protected]> > > > Sent: Thursday, November 20, 2025 5:05 AM > > > To: [email protected] <[email protected]> > > > Subject: Re: [VOTE] Add support to NOT POSIX Compliant (or should be > add > > support ?) > > > > > > Hi Greg, > > > > > > Yes, I think the idea is to support POSIX subprofiles, this is the case > > for > > > pthread, posix timers, signals, etc. > > > > > > I think these extreme cases are low end MCUs where we can offer the > > option > > > to run a small version of NuttX, without jeopardizing the usage for > > people > > > who need a compliant POSIX OS. > > > > > > BR, > > > > > > Alan > > > > > > On Thu, Nov 20, 2025 at 9:50 AM Gregory Nutt <[email protected]> > > wrote: > > > > > > > There should only be extreme conditions where any POSIX API is > > > > non-compliant. POSIX complience is a core value of the OS and should > > not > > > > be violated. If we lose POSIX compliance then we have destroyed the > > > > meaning for the existence of the operating system. I hopr that no > one > > will > > > > ever tolerate that to happen. > > > > > > > > The only legitimate cases I can think of are due to hardware > > limitations. > > > > For example, certain features of mmap() and fork() cannot be support > if > > > > there is no MMU. uCLinux had the same limitations. > > > > ________________________________ > > > > From: Alan C. Assis <[email protected]> > > > > Sent: Thursday, November 20, 2025 4:39 AM > > > > To: dev <[email protected]> > > > > Subject: [VOTE] Add support to NOT POSIX Compliant (or should be add > > > > support ?) > > > > > > > > Hi Everyone, > > > > > > > > Some years ago NuttX was able to fit in really small MCUs (in fact I > > got it > > > > running on a chip using less than 2KB RAM). > > > > > > > > But a few years ago those options to disable SIGNALS, VFS, etc were > > > > disabled to create a system that was fully POSIX compliant. > > > > > > > > Unfortunately we missed the details: POSIX also aims at systems > without > > > > resources, as is the case of POSIX PE51 (POSIX PSE51 is a specific, > > minimal > > > > profile or subset of the full POSIX - Portable Operating System > > Interface > > > > standard, formally defined in IEEE 1003.13-2003). > > > > > > > > Almost two years ago I opened an issue about it: > > > > https://github.com/apache/nuttx/issues/11390 > > > > > > > > Today Mr Chengdong opened a PR to bring back the possibility to > disable > > > > signals: > > > > https://github.com/apache/nuttx/pull/17352 > > > > > > > > But as Mateusz (raiden00pl) pointed we need to be careful about it to > > avoid > > > > breaking the Inviolables: > > > > > > > > ## Strict POSIX compliance > > > > > > > > - Strict conformance to the portable standard OS interface as > > defined at > > > > OpenGroup.org. > > > > > > > > > > > > * - A deeply embedded system requires some special support. Special > > > > support must be minimized.* - The portable interface must never be > > > > compromised only for the sake of > > > > expediency. > > > > - Expediency or even improved performance are not justifications > for > > > > violation of the strict POSIX interface. > > > > > > > > Fortunately Greg chose well his words: "Special support must be > > minimized". > > > > It doesn't mean it could exist, we just need to take care to not > become > > > > normal or goal and jeopardize the system. > > > > > > > > So in this sense I propose to vote a suggestion: > > > > > > > > In the configuration where we already add an option to disable posix > > timer, > > > > pthreads, etc we add an option to "Enable POSIX PE51 subset". > > > > > > > > This way someone willing to disable signals will be aware he/she is > > > > creating a system that is not POSIX fully compliant or it is just a > > subset > > > > of a POSIX OS. > > > > > > > > BR, > > > > > > > > Alan > > > > > > >
