POSIX never defined time as 32-bit. Older versions of POSIX simply didn't touch on this issue, allowing for freedom in implementation. The increase in memory usage isn't primarily due to newer POSIX versions, but rather to the fact that the first releases of NuttX didn't support all interfaces and features defined by the standard. Selecting a POSIX version from Kconfig won't help here. Selecting a POSIX profile may help (PSE51/PSE52), but the better option is to disable POSIX features from Kconfig (like it's done now) and make NuttX POSIX-incompatible at the user's request. Fine-tuning has always been a great feature of NuttX and still is, it just requires a little work from the user.
czw., 9 lip 2026 o 01:44 Nathan Hartman <[email protected]> napisał(a): > Well maybe there are opportunities to shrink the code size & stack usage > without compromising on POSIX. > > Idea: just as C/C++ compilers allow you to choose the standard version > (e.g., we choose ISO C90 even though it was superseded several times, C99, > C11, C23), we can consider letting NuttX users choose which POSIX version > they want. So they can choose an older version that has fewer requirements > and get smaller code size. This idea honors the INVIOLABLES: strict POSIX > compliance, and also honors the INVIOLABLES: all users matter, including > users who want to use older POSIX standard. Want a 32-bit time_t? Choose > the older POSIX standard in Kconfig. > > > On Wed, Jul 8, 2026 at 11:53 AM Alan C. Assis <[email protected]> wrote: > > > Hi Greg, > > > > True, unfortunately we didn't pay too much attention to how the size was > > increasing. > > Actually only one or two people doing review used to request to show the > > size increase on some PRs, although they appear small (few bytes or few > > dozens of bytes, now to tens of KBs). > > > > At least now we will spot any increase automatically thanks to MemBrowse > > integration on our github. > > > > BR, > > > > Alan > > > > On Wed, Jul 8, 2026 at 12:37 PM Gregory Nutt <[email protected]> > wrote: > > > > > If we are 2Kb short of 64Kb, then we are already at that threshold of > > 64Kb > > > support. You probably cannot make a legitimate application that > actually > > > does anything on the effected platforms now. A 2Kb savings now would > > only > > > be a stopgap measure as the size will certainly continue to grow and > will > > > likely consume that freed 2Kb in a few months. What would you do > then? > > > Put in another POSIX compliancy to work around the addition al size. > > > > > > It seems to me that unless there is an effort with larger scope than > this > > > then we can write off 64Kb support either now or in the next few months > > but > > > bad bandages. Bandages will not do the job in the long term. In the > > long > > > term they only corrupt the POSIX compliancy and the clean design. > > > > > > > > > > > > > > > > > > ________________________________ > > > From: Alan C. Assis <[email protected]> > > > Sent: Wednesday, July 8, 2026 6:27 AM > > > To: [email protected] <[email protected]> > > > Cc: Tiago Medicci Serrano <[email protected]> > > > Subject: Re: Make NuttX Tiny Again (pun intended) > > > > > > 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 > > > > > >>>> > > > > > >>> > > > > > > > > > >
