k_cycle_get_32() API is useless in some Zephyr configurations #16238
Comments
pizi-nordic
added
bug
|
FYI: @nashif, @andrewboie, @carlescufi |
|
what I think is needed is a new, private z_ prefixed API, like z_sys_runtime_clock_hw_cycles_per_sec() which returns runtime calculated system clock frequency. make it a system call. and then wrap sys_clock_hw_cycles_per_sec to either call that or just return CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC |
|
I would rather name it k_cycle_freq_get() in order to relate it to k_cycle_get_32(). IMHO on platforms witch clock speed known at compile time, it could be a static inline returning constant value and syscall on the others. What do you think? |
I don't care what you call it, but you can't ifdef its definition. |
Ok. I have not known that. |
If the system sets its clock frequency at runtime, this is stored in a variable that can't be directly read by user mode. For this case only, add a system call to fetch its value and modify the definition of sys_clock_hw_cycles_per_sec() to use it. Since this is now a system call, store in a temporary variable inside z_ms_to_ticks(). The syscall overhead only applies when called from user mode, other contexts are completely inlined. Added stub syscall header for mocking framework, to get rid of inclusion errors. Fixes: zephyrproject-rtos#16238 Signed-off-by: Andrew Boie <[email protected]>
If the system sets its clock frequency at runtime, this is stored in a variable that can't be directly read by user mode. For this case only, add a system call to fetch its value and modify the definition of sys_clock_hw_cycles_per_sec() to use it. Since this is now a system call, store in a temporary variable inside z_ms_to_ticks(). The syscall overhead only applies when called from user mode, other contexts are completely inlined. Added stub syscall header for mocking framework, to get rid of inclusion errors. Fixes: #16238 Signed-off-by: Andrew Boie <[email protected]>
TL;DR:
CONFIG_USERSPACE=y+CONFIG_TIMER_READS_ITS_FREQUENCY_AT_RUNTIME=y= No reference for k_cycle_get_32().The
CONFIG_USERSPACEoption introduces strong separation between the application and thekernel memory. The
CONFIG_TIMER_READS_ITS_FREQUENCY_AT_RUNTIMEmakes theCONFIG_SYS_CLOCK_HW_CYCLES_PER_SECdefine useless leaving thesys_clock_hw_cycles_per_sec()function the only source of system timer frequency, which is needed to interpret data from k_cycle_get_32().Unfortunately, the
sys_clock_hw_cycles_per_sec()function directly reads the kernel memory (z_clock_hw_cycles_per_sec) triggering exception when called from user thread.Please also note, that
sys_clock_hw_cycles_per_sec()is used in multiple inline functions, so other timing-related API also fails with the mentioned configuration.The text was updated successfully, but these errors were encountered: