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 >
