I'm not super-opposed to adding support for a different OS standard, but
it is certainly way too early to consider a vote. Remember that a single
-1 is sufficient to veto a code change (see "Votes on code modification"
in https://www.apache.org/foundation/voting.html). Certainly there are
people who would vote -1 if the vote is held today.
You really need to discuss implications and the changes to the code to
make the community feel at ease. I would allow a couple of weeks to a
month to get to that point.
If the changes are risky or invasive or result in a morass of
conditional compilation, perhaps we would want to fork NuttX into a
separate OS for these platforms???
On 11/20/25 12:40, Tomek CEDRO wrote:
-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
