lib: posix: nanosleep

[cfriedt]

This change adds support for nanosleep(2) documented at
https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html

Note: Does not achieve any greater resolution than that provided by k_busy_wait(us) but at least makes the API available.

I've not researched it much in Zephyr, but I would say there is still some work to be done for a generic clock API - one that allows querying resolutions, supports multiple system clocks, etc, primarily to support POSIX time APIs.

A nanosleep system call would also require high-res timer support (See #6498)

Fixes #25554

[zephyrbot]

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[cfriedt]

I have a feeling there is a conflict with CONFIG_BOARD_NATIVE_POSIX
CONFIG_BOARD_NATIVE_POSIX_64BIT

[pfalcon]

I have a feeling there is a conflict with CONFIG_BOARD_NATIVE_POSIX
CONFIG_BOARD_NATIVE_POSIX_64BIT

I'm not sure what exactly you mean (that native_posix and native_posix_64 boards conflict between each other?), but otherwise it's a known problem that Zephyr POSIX subsys conflicts with native_posix board. It should be understanding why - it's too layery a pie, where Zephyr POSIX subsys sits on top of native Zephyr core, and naive_posix boards tries to implement that in terms of the underlying full-POSIX system. Something doesn't match regularly. Many a POSIX tests/samples simply blacklist native_posix.

[cfriedt]

I have a feeling there is a conflict with CONFIG_BOARD_NATIVE_POSIX
CONFIG_BOARD_NATIVE_POSIX_64BIT

I'm not sure what exactly you mean (that native_posix and native_posix_64 boards conflict between each other?), but otherwise it's a known problem that Zephyr POSIX subsys conflicts with native_posix board. It should be understanding why - it's too layery a pie, where Zephyr POSIX subsys sits on top

That's what I meant. Sorry, was on mobile when I commented previously.

[cfriedt]

Should be good to go now

$ ./scripts/sanitycheck --enable-slow --inline-logs -j8 --testcase-root tests/posix/common
Renaming output directory to /home/cfriedt/workspace/zephyrproject/zephyr/sanity-out.24
INFO    - JOBS: 8
INFO    - Selecting default platforms per test case
INFO    - Building initial testcase list...
INFO    - 26 test configurations selected, 972 configurations discarded due to filters.
INFO    - Adding tasks to the queue...
INFO    - Total complete:   26/  26  100%  skipped:    0, failed:    0
INFO    - 26 of 26 tests passed (100.00%), 0 failed, 0 skipped with 0 warnings in 179.42 seconds
INFO    - In total 4 test cases were executed on 13 out of total 250 platforms (5.20%)
INFO    - 20 tests executed on platforms, 6 tests were only built.

[cfriedt]

Btw, the variance in latency (in CI / qemu) is pretty drastic between architectures. E.g. on qemu_cortex_r5, it was 500us, on xtensa it was 86 us, and on qemu_cortex_m3 it was 25us.

Sample size of 1, not statistically representative, of course.

Otherwise, I would have added a more stringent check than

/* should be more accurate than ns + 1 tick period */

Also, not 100% certain if this counts as a system call or a libc function. I assumed that it would be a libc function. There is no corresponding Zephyr system call, atm. However, pointers are passed in (NULL check is made, but otherwise no address space validation).

Edit: Even qemu_x86 (I guess with heavy server load?) over 10 ms of latency.

dt_ns: 1010136310

    Assertion failed at WEST_TOPDIR/zephyr/tests/posix/common/src/nanosleep.c:198: common: (dt_ns < ns + NS_PER_TICK is false)
expected: dt_ns < 1010000000 actual: 1010136310

Giving up on that upper-bounds test for now, as I don't think it can be reliably proved in CI.

[pfalcon]

Thanks!

[pfalcon]

@cfriedt, Thanks for the patch. I would personally recommend this merged for 2.3, but per the release freeze rules, 2 reviews are required at this time. I've added @carlescufi who both could review and merged (but definitely busy with a lot of other stuff now, as the release manager for this version), but feel free ping other folks who you know can help with review.

[cfriedt]

@cfriedt, Thanks for the patch. I would personally recommend this merged for 2.3, but per the release freeze rules, 2 reviews are required at this time. I've added @carlescufi who both could review and merged (but definitely busy with a lot of other stuff now, as the release manager for this version), but feel free ping other folks who you know can help with review.

It would be awesome if nanosleep could actually get relatively close to the exact time (if there is hardware to support it). The high-res timer stuff is pretty important though, and I think it deserves a great deal of care. No rush on that one. The nice thing about it though is that the interface is there, and it's not moving, so just redoing the implementation later will have no unwanted side-effects.

[jukkar]

Looks good, minor nit about the macro name that was missed from previous cleanup.

[cfriedt]

@carlescufi - rebased off master / using <stdint.h> integer types. Should be good to go as long as the build works.

[cfriedt]

Was green before. Looks like there is some misra change that breaks things atm

[pfalcon]

some misra change

New swear word in software engineering? ;-)

[pfalcon]

starting test - test_timeout_lifo_thread

    Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/lifo/lifo_usage/src/main.c:329: test_timeout_lifo_thread: packet != NULL is false

FAIL - test_timeout_lifo_thread

I got such a failure in one of my recent PR. Looks like nondeterministic failure du jour.

@cfriedt: Please keep rebasing this, until sweet spot is found.