Hi, If we intend to use the `INVIOLABLES.md`, we need to use it fully. This isn't a question about it, IMHO. 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.* Best regards, Em qua., 8 de jul. de 2026 às 10:48, Sebastien Lorquet <[email protected]> escreveu: > Hello > > Quoting INVIOLABLES.md > > > All Users Matter > > ... > > # We should seek to expand the NuttX user base, not to limit it for > reasons of preference or priority. > # We must resist the pull to make NuttX into a Linux-only, GCC-only, and > ARM-only solution. > > > > Sebastien > > > On 7/8/26 15:44, Tiago Medicci Serrano 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 > >>>>> > >>>>> Beforehttps://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 > >>>>>>>>
