Hello,

I also think that we should rather seek PE51 compatibility rather than disabling specific POSIX functions arbitrarily.

kconfig can be explicit to state that the option enables some support that will end up being PE51 even if incomplete yet.

For example: "Enable POSIX PE51 profile features (Still incomplete)" and condition it on EXPERIMENTAL maybe

(meta: this thread looks more like a DISCUSS than a VOTE. if it' a vote then thats a -1 for me)

Sebastien


On 11/20/25 14:10, Alan C. Assis wrote:
Hi Nathan,

That was exactly my question mark when Mateusz raised this issue.

Later (few minutes ago) he shed some light on it:

Seems like we still missing some functionalities to support POSIX PE51:
https://nuttx.apache.org/docs/latest/standards/posix.html

So, maybe adding "Enable POSIX PE51 profile" could induce people to thing
NuttX is already POSIX PE51 compliant (but it is not yet)

Maybe we can act fast to fix these gaps and get complete support to PE51.

BR,

Alan

On Thu, Nov 20, 2025 at 10:04 AM Nathan Hartman <[email protected]>
wrote:

I agree with what Greg said, but I'm a little bit confused: if POSIX
provides PE51 for supporting very limited systems, and that's a possibility
POSIX itself provides, then how does supporting that violate POSIX or the
Inviolables? If anything, providing an option to build as a POSIX
PE51-compliant system would add more support for POSIX, for not less. Or am
I misunderstanding something?

Thanks,
Nathan

On Thu, Nov 20, 2025 at 7: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

Reply via email to