+1, please go ahead! Just mark the PR as breaking change.
BTW, I think this change will break all existing programs that rely on CLOCKS_PER_SEC, in our nuttx-apps: netutils/ftpc system/cpuload system/resmonitor testing/testsuites Many users' programs will probably fail on the next NuttX release. This will be significant enough to target a NuttX 14 release! BR, Alan On Fri, Oct 23, 2026 at 5:41 AM Marco C. <[email protected]> wrote: > Hello Xiang, > > Thank you. I agree: no Kconfig option. CLOCKS_PER_SEC will always be > 1000000, as the specification requires. > > If there are no objections, these are the next steps: > > 1. I open steps 1 and 2 as normal pull requests. They do not change > behaviour. > 2. I open step 3 as a draft pull request, with the "!" mark and the > BREAKING CHANGE section, and I add the link to this thread. > 3. When the build and runtime logs from real hardware are in the pull > request, I start the vote. > > Thank you, > Marco Casaroli > > On Fri, Oct 23, 2026 at 10:26 AM Xiang Xiao <[email protected]> > wrote: > > > > It's always a bad idea to add a Kconfig option which changes the > > visible behavior difference for the same function, > > how could we write a program which uses CLOCKS_PER_SEC behaviour > > consistently regardless of the option value? > > so, it's better to make it always confirm the spec or not change it at > all. > > > > On Fri, Oct 23, 2026 at 4:11 PM Marco C. <[email protected]> > wrote: > > > > > Hello, > > > > > > I want to discuss a breaking change before I open the pull request, as > > > CONTRIBUTING.md 1.13 asks. > > > > > > The problem > > > > > > In NuttX, CLOCKS_PER_SEC is the system tick rate (1000000 / > > > CONFIG_USEC_PER_TICK, 100 by default), and clock() returns system > > > ticks. POSIX requires CLOCKS_PER_SEC to be 1000000 on XSI systems: > > > > > > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/time.h.html > > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/clock.html > > > > > > Issue #3516 (2021) reported this: > > > https://github.com/apache/nuttx/issues/3516. A comment there says that > > > ISO C allows any value. That is correct, but programs written for > > > POSIX systems expect 1000000, and the Open POSIX Test Suite checks it > > > (conformance/interfaces/clock/2-1.c). Also, the same macro has two > > > meanings in NuttX today: 22 files in arch/, drivers/, fs/ and sched/ > > > use CLOCKS_PER_SEC as the tick rate, where CLK_TCK or TICK_PER_SEC is > > > the correct name. > > > > > > The proposal, in three steps > > > > > > 1. nuttx-apps: netutils/ftpc and system/cpuload use CLK_TCK for the > > > tick rate. CLK_TCK has the same value as CLOCKS_PER_SEC today, so > > > nothing changes. > > > 2. nuttx: the 22 files use CLK_TCK for the tick rate. The generated > > > code does not change. > > > 3. nuttx, the breaking change: CLOCKS_PER_SEC is 1000000 and clock() > > > returns microseconds. times() and sysconf(_SC_CLK_TCK) stay in ticks > > > (CLK_TCK). clock_t is int64_t, so the value does not overflow. > > > > > > Steps 1 and 2 do not change behaviour. I can send them as normal pull > > > requests now. Only step 3 needs the vote. > > > > > > What breaks with step 3 > > > > > > - Code that uses CLOCKS_PER_SEC as the number of ticks per second, for > > > example to convert seconds into a timeout for wd_start() or > > > nxsig_usleep(). Quick fix: use CLK_TCK or TICK_PER_SEC. > > > - Code that divides clock() by CLOCKS_PER_SEC needs no change. > > > - In protected and kernel builds, clock() is a system call. Programs > > > built with the old header must be built again. > > > > > > The resolution of clock() does not change: it still advances once per > > > tick. Only the unit changes. clock() also still returns the time since > > > boot, not the processor time of the process (the other point of > > > #3516); this proposal does not change that. > > > > > > A non-breaking alternative > > > > > > A Kconfig option selects CLOCKS_PER_SEC = 1000000, and it is off by > > > default. Steps 1 and 2 stay the same. The problem: the value of a > > > standard macro then depends on the configuration, so code that uses > > > CLOCKS_PER_SEC as the tick rate breaks only in some configurations, > > > and later. > > > > > > Tests so far > > > > > > QEMU (qemu-armv8a:knsh): a test program checks CLOCKS_PER_SEC, and > > > that clock() and times() both measure 0.5 s of processor time > > > correctly. ostest passes on qemu-armv8a:nsh. Seven configurations > > > build (flat, protected and kernel; arm64, armv7-m, rv64, x86_64). > > > Before a vote, I will add build and ostest logs from real hardware of > > > more than one architecture, as CONTRIBUTING.md 1.14 requires. > > > > > > Questions > > > > > > 1. Do you agree with the change, or do you prefer the Kconfig option? > > > 2. Is it OK to send steps 1 and 2 now as normal pull requests? > > > > > > Thank you, > > > Marco Casaroli > > > >
