I agree with Tiago, I think our focus shouldn't be on shrinking NuttX by disabling POSIX features (at least, not right away), but instead we should find other areas we can optimize. I remember we now have the ability to turn off POSIX signals (?) which helped the code size, which was a nice feature. However, every time we do that it'll be hard to figure out what the impact is (what apps depend on signals, and how do we reliably mark all those dependencies in Kconfig?).
I personally think that the current NuttX mainline has enough issues right now, it would be better to shrink internal features and squash bugs than start adding toggles for POSIX features. I think that could become messy quickly. Matteo On Wed, Jul 8, 2026 at 10:32 AM Tiago Medicci Serrano < [email protected]> wrote: > Hi, > > From my side, I'm against creating exceptions that go against our main > goal (the reason NuttX exists), even more so without proper data to support > it, not as a technical argument, but as a commercial decision. > > About Zephyr, well, they support 3 (out of 1K+). And, again, we are not > Zephyr. People use Zephyr for other reasons. People use NuttX because it's > POSIX-compatible. > [image: image.png] > > IMHO, we should not create such a kind of exception. Jumping out of this > discussion for now. > > Best regards, > > Em qua., 8 de jul. de 2026 às 11:14, Alan C. Assis <[email protected]> > escreveu: > >> Tiago, >> support for small MCUs open NuttX usages for new users and scenarios. >> >> We don't need to do a market analysis to discover it. >> All companies' goal is to reduce costs, so they will select the smaller >> MCU that solves their issue and the RTOS that fit on it. >> >> It is not if there is a market for these MCUs (otherwise they shouldn't >> be produced) , it is if there is a RTOS for these MCUs. >> >> And the answer is clear, there is: >> https://docs.zephyrproject.org/latest/boards/index.html#ram-max=2&flash-max=16 >> >> BR, >> >> Alan >> >> On Wed, Jul 8, 2026 at 10:44 AM Tiago Medicci Serrano < >> [email protected]> wrote: >> >>> Hi! >>> >>> Do we have any metrics about such chips? Does anyone use them? This is >>> important to build a strong opinion on whether to create exceptions given >>> our limited resources and the availability of more modern chips and >>> features to be implemented. >>> >>> My point is all about focusing on what matters. Eventually, some chips >>> may be lost while NuttX (or any other OS) evolves. This is something >>> natural for any project. To create exceptions, we need to think of NuttX as >>> a product. Do we have customers that require it? How important is that? >>> >>> Best regards, >>> >>> Em qua., 8 de jul. de 2026 às 10:27, Alan C. Assis <[email protected]> >>> escreveu: >>> >>>> Exactly! That is the point! >>>> >>>> It will be an option for people using MCUs with < 64KB Flash memory. >>>> Thank you Karel. >>>> >>>> My suggestion add inside: >>>> RTOS Features --> >>>> [*] Disable NuttX interfaces >>>> [*] Disable POSIX Compatibility (default N and depends on >>>> DEFAULT_SMALL) >>>> Only after this option user will be able to disable TIME64 >>>> and LIBC_LONG_LONG >>>> >>>> Also, I think the "DEFAULT_SMALL" symbol is a confusing name, I suggest >>>> renaming it to "SMALL_KERNEL" or similar. >>>> >>>> BR, >>>> >>>> Alan >>>> >>>> On Wed, Jul 8, 2026 at 10:07 AM Karel Kočí <[email protected]> wrote: >>>> >>>>> Hi >>>>> >>>>> My two cents: >>>>> >>>>> * Nobody is suggesting to break POSIX compatibility for everyone. >>>>> Alan's >>>>> suggestion is to have option to break it to reduce the size. >>>>> * It might be worth it to explicitly track chips that do support POSIX >>>>> in NuttX >>>>> fully and those that need compromises. >>>>> >>>>> Just two cents.. >>>>> Karel >>>>> >>>>> >>>>> On Wed 08 Jul 2026 07:49:10 AM , Tiago Medicci Serrano wrote: >>>>> > Hi! >>>>> > >>>>> > I don't think NuttX getting bigger is an issue at all. Of course, we >>>>> should >>>>> > care about code size: this is an important metric to be aware of, >>>>> and we >>>>> > should avoid unnecessary code. >>>>> > >>>>> > This is not the case here. The recent code changes are required to be >>>>> > compatible with modern POSIX systems. Removing them just to fit on >>>>> smaller >>>>> > MCUs would be intentionally making NuttX worse just to make it fit >>>>> into >>>>> > MCUs that we don't have any usage analytics for. >>>>> > >>>>> > Systems evolve. Linux kernel is deprecating support for older CPUs. >>>>> > >>>>> > People use NuttX because it's POSIX-compatible and the burden of >>>>> migrating >>>>> > applications is lower: that's the goal we should pursue first, IMHO. >>>>> > People use Zephyr for other reasons. >>>>> > >>>>> > Best regards, >>>>> > >>>>> > Em ter., 7 de jul. de 2026 às 17:08, Alan C. Assis < >>>>> [email protected]> >>>>> > escreveu: >>>>> > >>>>> > > I know it was discussed a lot, but I think removing >>>>> CONFIG_LIBC_LONG_LONG >>>>> > > alone (because TIME64) added about 2KB: >>>>> > > >>>>> > > Current mainline: >>>>> > > >>>>> > > $ arm-none-eabi-size nuttx >>>>> > > text data bss dec hex filename >>>>> > > 64008 1548 3996 69552 10fb0 nuttx >>>>> > > >>>>> > > Before https://github.com/apache/nuttx/pull/18840 (at commit >>>>> > > 4f6e695f7c56aa5a321008ca8e5ddd47e1959e4d) : >>>>> > > >>>>> > > $ arm-none-eabi-size nuttx >>>>> > > text data bss dec hex filename >>>>> > > 61936 1548 3764 67248 106b0 nuttx >>>>> > > >>>>> > > For 64KB Flash, these 2KB doesn't appear too much, but consider >>>>> that these >>>>> > > are 2KB that we never can get rid of. >>>>> > > >>>>> > > So, few years ago NuttX was able to fit inside a 32KB and 4KB RAM >>>>> MCU: >>>>> > > (LPC1114FN28: >>>>> > > https://www.flickr.com/photos/79703543@N00/18013069041/sizes/l/ ) >>>>> > > >>>>> > > If we keep increasing at this rhythm very soon people will have >>>>> another >>>>> > > reason to use Zephyr: https://gzm-emb.com/blog/zephyr-16kb/ (in >>>>> this >>>>> > > example it was 105KB Flash and 16KB, so we still have hope). >>>>> > > >>>>> > > The same way we reconsidered the signals, I think we should give >>>>> the user >>>>> > > the option to disable TIME64 and LIBC_LONG_LONG and run NuttX on >>>>> small MCUs. >>>>> > > >>>>> > > BR, >>>>> > > >>>>> > > Alan >>>>> > > >>>>> > > On Tue, Jul 7, 2026 at 12:17 PM Alan C. Assis <[email protected]> >>>>> wrote: >>>>> > > >>>>> > >> Hi Michael, >>>>> > >> >>>>> > >> Thank you very much, in fact the printf implementation that NuttX >>>>> uses >>>>> > >> currently was contributed by Keith Packard himself some years ago. >>>>> > >> >>>>> > >> But I don't know how it compares to his new picolibc. >>>>> > >> >>>>> > >> BR, >>>>> > >> >>>>> > >> Alan >>>>> > >> >>>>> > >> On Tue, Jul 7, 2026 at 11:50 AM Michael Jung < >>>>> [email protected]> >>>>> > >> wrote: >>>>> > >> >>>>> > >>> Hi Alan, all, >>>>> > >>> >>>>> > >>> I believe picolibc has a very size efficient implementation of >>>>> printf >>>>> > >>> and scanf. See Keith's talk >>>>> https://www.youtube.com/watch?v=e3Vxr0iLIUE >>>>> > >>> at minute 13:06. >>>>> > >>> >>>>> > >>> Bye, >>>>> > >>> Michael >>>>> > >>> >>>>> > >>> On Tue, Jul 7, 2026 at 4:33 PM Alan C. Assis <[email protected]> >>>>> wrote: >>>>> > >>> >>>>> > >>>> Hi Everyone, >>>>> > >>>> >>>>> > >>>> Seems like we NuttX got great in the last few years. >>>>> > >>>> >>>>> > >>>> Although in general it is still using very little RAM memory >>>>> and it >>>>> > >>>> uses a lot of Flash. >>>>> > >>>> >>>>> > >>>> So, even boards with 64KB of Flash are breaking: >>>>> > >>>> >>>>> > >>>> >>>>> ==================================================================================== >>>>> > >>>> >>>>> > >>>> Cmake in present: >>>>> > >>>> nucleo-f302r8/ihm07m1_b16,CONFIG_ARM_TOOLCHAIN_GNU_EABI >>>>> > >>>> Configuration/Tool: >>>>> > >>>> nucleo-f302r8/ihm07m1_b16,CONFIG_ARM_TOOLCHAIN_GNU_EABI >>>>> > >>>> 2026-07-07 13:44:43 >>>>> > >>>> >>>>> ------------------------------------------------------------------------------------ >>>>> > >>>> >>>>> > >>>> Cleaning... >>>>> > >>>> Configuring... >>>>> > >>>> Select HOST_LINUX=y >>>>> > >>>> TOOLS_DIR path is "/github/workspace/sources/nuttx" >>>>> > >>>> HOST = Linux >>>>> > >>>> Disabling CONFIG_ARM_TOOLCHAIN_GNU_EABI >>>>> > >>>> Enabling CONFIG_ARM_TOOLCHAIN_GNU_EABI >>>>> > >>>> Building NuttX... >>>>> > >>>> TOOLS_DIR path is "/github/workspace/sources/nuttx" >>>>> > >>>> HOST = Linux >>>>> > >>>> [1/5] cd /github/workspace/sources/nuttx/build/libs/libc/misc && >>>>> > >>>> /usr/local/bin/cmake -E touch >>>>> > >>>> /github/workspace/sources/nuttx/libs/libc/misc/lib_utsname.c >>>>> > >>>> [2/5] Linking C executable nuttx >>>>> > >>>> FAILED: nuttx >>>>> > >>>> : && /tools/ccache/bin/arm-none-eabi-gcc --specs=nosys.specs >>>>> > >>>> -Wl,--print-memory-usage -Wl,--entry=__start -nostdlib >>>>> -Wl,--gc-sections >>>>> > >>>> -Wl,--cref -Wl,-Map=nuttx.map @CMakeFiles/nuttx.rsp -o nuttx && >>>>> : >>>>> > >>>> >>>>> /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: >>>>> > >>>> nuttx section `.data' will not fit in region `flash' >>>>> > >>>> >>>>> /tools/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: >>>>> > >>>> region `flash' overflowed by 4 bytes >>>>> > >>>> Memory region Used Size Region Size %age Used >>>>> > >>>> flash: 65540 B 64 KB 100.01% >>>>> > >>>> sram: 5556 B 16 KB 33.91% >>>>> > >>>> collect2: error: ld returned 1 exit status >>>>> > >>>> ninja: build stopped: subcommand failed. >>>>> > >>>> cp: cannot stat 'nuttx.hex': No such file or directory >>>>> > >>>> cp: cannot stat 'nuttx.bin': No such file or directory >>>>> > >>>> cp: cannot stat 'nuttx.hex': No such file or directory >>>>> > >>>> cp: cannot stat 'nuttx.bin': No such file or directory >>>>> > >>>> /github/workspace/sources/nuttx /github/workspace/sources/nuttx >>>>> > >>>> >>>>> > >>>> It is important to notice that CONFIG_DEFAULT_SMALL is already >>>>> defined >>>>> > >>>> to it. >>>>> > >>>> >>>>> > >>>> Analyzing the 20 biggest functions there is not a single >>>>> culprit, so >>>>> > >>>> probably we need to reduce the overall functions size: >>>>> > >>>> >>>>> > >>>> $ arm-none-eabi-nm --print-size --size-sort --radix dec -C >>>>> nuttx | grep >>>>> > >>>> ' [TtWw] ' | tail -20 >>>>> > >>>> 134243508 00000390 t pwm_configure >>>>> > >>>> 134217728 00000392 T _vectors >>>>> > >>>> 134229344 00000396 t adc_read >>>>> > >>>> 134249208 00000400 t file_vioctl >>>>> > >>>> 134218408 00000424 T stm32_configgpio >>>>> > >>>> 134269892 00000448 T motor_aobserver_nfo_b16 >>>>> > >>>> 134231544 00000448 t uart_writev >>>>> > >>>> 134239368 00000460 t stm32_foc_setup >>>>> > >>>> 134261888 00000468 T parse_args >>>>> > >>>> 134264176 00000500 T foc_motor_init >>>>> > >>>> 134263096 00000540 T foc_fixed16_thr >>>>> > >>>> 134256256 00000540 T nxsig_tcbdispatch >>>>> > >>>> 134233432 00000540 t uart_ioctl >>>>> > >>>> 134265056 00000612 T foc_motor_control >>>>> > >>>> 134265668 00000648 T foc_motor_handle >>>>> > >>>> 134231992 00000652 t uart_readv >>>>> > >>>> 134260828 00000692 T foc_main >>>>> > >>>> 134252412 00000700 T __udivmoddi4 >>>>> > >>>> 134245448 00000860 t nsh_parse_command >>>>> > >>>> 134258408 00001234 t vsprintf_internal.constprop.0 >>>>> > >>>> >>>>> > >>>> I can't resist to ask the Claude to analyze these data, and it >>>>> gave us >>>>> > >>>> some picture of current code tree: >>>>> > >>>> >>>>> > >>>> [image: image.png] >>>>> > >>>> >>>>> > >>>> And seems like NSH and printf (vsprintf) are the biggest >>>>> offenders: >>>>> > >>>> >>>>> > >>>> [image: image.png] >>>>> > >>>> >>>>> > >>>> So, if someone has some suggestions on how we can improve this >>>>> > >>>> scenario, please let me know. >>>>> > >>>> >>>>> > >>>> At least now we have the option to disable some important >>>>> features like >>>>> > >>>> signals (that unfortunately will break POSIX compatibility). >>>>> But maybe we >>>>> > >>>> can apply some diet to NSH and printf to improve it. >>>>> > >>>> >>>>> > >>>> BR, >>>>> > >>>> >>>>> > >>>> Alan >>>>> > >>>> >>>>> > >>> >>>>> >>>>
