The proposal doesn't remove the signal support from the code base, but make it configurable. So, the user still could keep the signal function if they want. If CONFIG _DISABLE _SIGNALS isn't allowed, we should remove all following config: DISABLE_POSIX_TIMERS DISABLE_PTHREAD DISABLE_MQUEUE DISABLE_ENVIRON DISABLE_MOUNTPOINT since all are required by POSIX too.
On Thu, Nov 20, 2025 at 9:05 PM 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 > > >
