Hello world :-)

Lets always have [DISCUSS] first before [VOTE] because we are not sure
what we are exactly voting for :-)

What this "POSIX PE51 subset" fixes exactly? Can we have comparison of
features against "full" POSIX and comparison of Flash/RAM memory
footprint? How much work is needed to get this implemented? Who will
do the job?

If we want to implement "POSIX PE51 subset" then such comparison
should be made in the first place and then discuss over. Also this
should be part of documentation so ursers will know what is this about
not necessarily search for some threads on the mailing list :-)

The Inviolables are sacred! The default is always "strict POSIX
compliance". We may create and provide "POSIX PE51 subset" but we need
clear documentation how it works, what it offers, what are advantages
and disadvantages. We don't know it for now and we don't have this
documented anywhere. Vote should take place when a prototype is ready,
before that we should discuss something that is clear and at least
documented.

On extremely tiny MCU most features are not really necessary, true,
except just for a scheduler, bootloader, selected drivers, and the
main() entry, this is how other RTOS work. This would enable NuttX on
really tiny / older devices. Kind of extreme case but myself I would
prefer to stick to NuttX and not other solution when this is really
needed. Would this comply with "special support for deeply embedded
systems" in the Inviolables  Greg?

Users can create such "minimalist" configuration on their own when
needed anyways, or just modify the local code to get this done, but
that is additional work hard to maintain in the long term. So maybe
instead creating additional templates we should just TAG
(code+kconfig+cmake) what functionalities provide "POSIX_API" and
"POSIX_PE51_API" and then it will be clear that if someone disable
something with "POSIX*" tag then POSIX compliance is lost, clearly on
purpose by the user and at the risk of user, but do the required job
is done? Wouldn't that provide simpler and more elegant solution for
corner cases like ultra tiny MCU and we still adhere to Inviolables?

Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Thu, Nov 20, 2025 at 1:39 PM Alan C. Assis <[email protected]> wrote:
>
> 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