Thanks Alan :-) Yes I generally agree with the trim-down idea, but we need to stay POSIX/ANSI compliant by design and by default as a project, some concepts on how to implement these trims/profiles the easy way already presented in the replies before, and we need to present solutions in a coherent form.. when voting we need a product ready to use :-)
I want to see NuttX on 1024B MCU!! =) Take care :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Nov 20, 2025 at 9:10 PM Alan C. Assis <[email protected]> wrote: > > 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: > > > 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 >> > > > > > >> > > > >> > >
