Tomek, Yes, I think this email subject is not helping either.
We need to discuss first if we want to add POSIX profiles, similar to way Zephyr did it: https://github.com/zephyrproject-rtos/zephyr/blob/main/lib/posix/Kconfig.profile Then we will vote if we want to create these profiles to let users to disable features to reduce the final firmware size. To people understand the impact of disabling signals, this is the test that Mateusz did in this smallest board configuration: [image: image.png] Today the minimum NuttX is around 18KB, disabling signals will be possible to run NuttX in MCUs with less than 8KB. And we are not removing signals from the kernel, it is just a configuration and as Nathan said we need to give the user the right to select when he wants to use. It doesn't destroy or jeopardize the OS, because NuttX will continue to be POSIX by default. We are just opening the possibility for people to run NuttX on small MCUs if (and only IF) he wants to run a small profile that doesn't have all POSIX features, but still meeting his project's goals (or hobbyist goals in some cases). BR, Alan On Thu, Nov 20, 2025 at 4:53 PM Tomek CEDRO <[email protected]> wrote: > Alan, Raiden, what is the exact proposition here being voted? > One sentence that can be answered yes or no. > > It looks like a proposition to make NuttX "NOT POSIX Compliant". > This violates fundamental architecutral concept and inviolables of NuttX. > Thus my answer is NO. > > Implication of answering yes here is enabling mess in the long term. > Because vote is not well defined, undocumented, with no examples or > prototypes, anything that is on purpose not POSIX compliant could > legally become part of NuttX making if purposefully non-posix > compliant which violates its founding principle, and all this could be > attributed to this vote. > > As a BSD Unix user on my desktop I understand that pretty well, NuttX > has BSD Unix roots too and I love it! > I will not tell anything about other OR/RTOS except they may not care > about self-compatibility and standards a lot, and people have choice > what to use or what to avoid. > > If anyone wants to trim down their firmware image removing all sorts > of unused parts, that is their choice, I am fine with that, I also > need that. > > But to introduce "NOT POSIX Compliant" to a project where "POSIX > Compliance" is a design principle looks self-contradictory. > > Lets have a discussion first, know the details, align the solution, then > vote. > Lets not vote by surprise because voting is binding. > > Hugs :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Thu, Nov 20, 2025 at 8:23 PM Alan C. Assis <[email protected]> wrote: > > > > 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 > > > > > > > > > > > > > >
