+1 for https://github.com/apache/nuttx/pull/17352
POSIX compatibility is the defining ethos of NuttX, and no one is permitted to compromise this feature across its full functional set. However, the standard NuttX kernel remains overly large for some resource-constrained IoT chips. Developers who favor NuttX would undoubtedly prefer a smaller memory footprint within their familiar development environment—one that preserves kernel integrity while offering optional configurations for certain features. (I once ported NuttX to an IoT platform with only 64KB of ram, and in terms of kernel size, it did not hold an advantage over other RTOS.) I believe configurability is also one of NuttX's key features. All POSIX-compliant capabilities are supported via Kconfig, while the same kernel size and performance as FreeRTOS can also be achieved through Kconfig configuration—this is extremely appealing to any developer. BRs, Matteo Golin <[email protected]> 于2025年11月20日周四 21:10写道： > If there exists a POSIX standard for that, I'm all for supporting it. I > think it should be clear to users what POSIX spec they are using (i.e. when > they cross the line from full POSIX to PE51). > > Matteo > > On Thu, Nov 20, 2025, 8:05 AM Alan C. Assis <[email protected]> wrote: > > > 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 > > > > > >
