Ah, this is very good idea, but why the PR author is not here and did not start the discussion as expected? o_O
-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Nov 20, 2025 at 9:17 PM Alan C. Assis <[email protected]> wrote: > > BTW, I'm saying that the idea of creating the VOTE image was yours, just > saying you commented we need to have a vote for that PR that disables > signals. ;-) > > BR, > > Alan > > On Thu, Nov 20, 2025 at 5:13 PM Alan C. Assis <[email protected]> wrote: > > > Mateusz, > > > > Since the idea of voting came from you in the first place, could you > > please start a separate thread to DISCUSS it? :-) > > > > BR, > > > > Alan > > > > On Thu, Nov 20, 2025 at 5:03 PM raiden00pl <[email protected]> wrote: > > > >> It's become quite a mess here, starting with the thread titled VOTE > >> without DISCUSSION :) The title also suggests that the lack of > >> POSIX compliance in NuttX is something new, which is not true. > >> > >> We've touched two separate topics here that I think deserve > >> their own separate discussion. The first topic: should we introduce > >> an option to disable signal support, similar to how we currently > >> disable pthreads or POSIX timers? Both options are not > >> POSIX-compliant, but are useful for small systems and they > >> have been in NuttX for a long time. > >> > >> The second topic is support for POSIX subprofiles (like PSE51), > >> but this is the topic for later. > >> > >> czw., 20 lis 2025 o 20:53 Tomek CEDRO <[email protected]> napisał(a): > >> > >> > 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 > >> > > > > > > > >> > > > > > >> > > > > >> > > >> > >
