Nuttx does support fork(), but only for a few architectures. An MMU is required to support fork() and full mmap() functionality. It is just physically impossible without an MMU. The same situation as for ucLinux (which uses vfork(). uCLinuxwas absorbed into Linux).
I'm not opposed to removing nsh from any specific configuration But you probably should not claim POSIX compatibility in those cases. We, in fact, cannot even really claim to be a POSIX OS. POSIX is a trademark of the OpenGroup and they do not permit any OS to claim to be POSIX compliant unless that OS has passed the OpenGroup POSIX compliance test and POSIX certified by the OpenGroup. I try to use only wording like POSIX compatible and avoid the phrase POSIX compliant. Xiamoi has worked with the LTS and made a lot of changes to pass those Linux tests. So this is really a matter of objectives: Are we satisfied to be only POSIX compatible or is full POSIX compliance on the roadmap? If the latter then be must be very careful and picayune. I imagine any future certification would be with the then current edition. ________________________________ From: Michał Łyszczek Sent: Thursday, July 9, 2026 12:45 PM To: [email protected] Subject: Re: Make NuttX Tiny Again (pun intended) On 2026-07-09 16:57:16, Gregory Nutt wrote: > A recent comment said that we could reduce size by eliminating NSH. However, > this seems to introduce addition POSIX incompatibilies. Posix mandates fork(2), and yet nuttx lacks one. You Greg, yourself added this exception if I'm not mistaken. So I don't see reason not to allow users to remove shell from their system. Shell on deeply embedded system is really not necessary. Some features are just WAY too heavy to let them live. I wouldn't really spend too much time removing posix things just to make OS smaller. But no fork(2) and no nsh(1) do seem like a great exceptions to the rule. You could probably find few more things to remove, but is it worth the maintenance burden? Nuttx is already stretched thin as it is and lacks hands. People are using Zephyr not because it's small or is some great RTOS, but because it's popular and has official "support" from OEMs. This goes long way. Companies will often just get next tier chip with bit more ram and flash so that zephyr can work there. Been there, seen that. I myself started using nuttx because it was posix and it was stable. Not because I could run it on 8bit atmega. If it were up to me I would just kill support for 8bit and 16bit MCUs (far pointers, eww). It sounds cool to support them, but it adds maintenance burden. And people will use something much smaller for 8bit and 16bit MCUs are used only by that one nerd that just love those shenanigans with memory addressing.
