lib: posix: add include/posix to search path and drop posix header prefix

[cfriedt]

It is a pain point to prefix standard POSIX APIs (e.g. #include <zephyr/posix/unistd.h>). This is true, in particular, when integrating third-party code into an external module. However, using the POSIX API should also not be a default in Zephyr.

With this, if users choose to include standard POSIX headers via Kconfig, then those headers will be part of the default search path. The headers themselves do not move. POSIX headers will not appear in the default search path unless so configured.

Additional changes:

• removed posix/time.h to mitigate need for #include_next workaround
• gathered NSEC_PER_MSEC and USEC_PER_MSEC defs intosys_clock.h
• restructured some syscalls (unistd, ioctl, clock)
• sprinkled #include <unistd.h> where close() is used or use zsock_close() instead
• removed a fair amount of duplicate code
• additional improvements planned to improve code sharing / coexistence with net API
• suggested minor changes to picolibc lib: libc: picolibc: time.h definitions and declarations #46910

Fixes #43998

[cfriedt]

Required module changes

• zephyr: remove posix prefix on time.h standard include hal_ti#32
• zephyr: check if BIT is defined before redefining hal_telink#2
• minimal libc + posix: add strerror and perror functions #46101

Unrelated failures
Pre-existing failures in main

• nucleo_f429zi: multiple networking tests failing #44486
• nucleo_h743zi failing twister builds due to NOCACHE_MEMORY warning #45073

Tests of primary concern

• twister -G -T tests/posix -T tests/net
• twister -b -T samples/posix -T samples/net
• twister -p native_posix_64 -T tests/net -T samples/net

Compliance and Coding Style test failures are false positives.

[cfriedt]

@keith-packard - can you be a bit more specific?
The C library uses POSIX functions for various operations, in particular, picolibc uses:

More or less what I anticipated as well, because newlib had similar overlap. The hazards look entirely manageable though, @keith-packard. I would say the one that could potentially be (hand-wavy) is open, but mainly because of fcntl.h.

Probably should not be used in the Zephyr (yet?)
isatty

Probably should not be used in Zephyr
getpid
kill

If there is any discrepancy, we will likely use the picolibc definitions
lseek
lseek64
fstat
open

Likely fine (Note: we use libc's <time.h>):
read
unlink
write
gettimeofday
close
_exit

[keith-packard]

More or less what I anticipated as well, because newlib had similar overlap. The hazards look entirely manageable though, @keith-packard. I would say the one that could potentially be (hand-wavy) is open, but mainly because of fcntl.h.

Zephyr currently has conflicting definitions for many of these APIs as it defines them as aliases for static inline functions. That means code including picolibc headers will not get the correct definitions, they'll get external function references, which may (or may not) work, but will certainly be less efficient.

I think what would be best would be for the standard posix headers to define the standard posix APIs generating the right code to operate in Zephyr. That means inline code for syscalls, for instance.

Given that the Zephyr SDK is already using a new GNU triplet including '-zephyr-', it's reasonable to expect the libraries in that SDK to be zephyr-specific, so if the C library is built as part of that toolchain, it can (and should) understand the Zephyr syscall interface, defining the functions correctly for use in Zephyr. Similarly, a C library built as part of Zephyr should use the Zephyr syscall interface.

Including hacks in Zephyr to work around libraries not designed for it is reasonable where you can't fix the library. In this case, the upstream projects would all be happy to accept Zephyr OS support.

[cfriedt]

More or less what I anticipated as well, because newlib had similar overlap. The hazards look entirely manageable though, @keith-packard. I would say the one that could potentially be (hand-wavy) is open, but mainly because of fcntl.h.

Zephyr currently has conflicting definitions for many of these APIs as it defines them as aliases for static inline functions.

This change fixes that.

I think what would be best would be for the standard posix headers to define the standard posix APIs generating the right code to operate in Zephyr. That means inline code for syscalls, for instance.

This change fixes that too.

Given that the Zephyr SDK is already using a new GNU triplet including '-zephyr-', it's reasonable to expect the libraries in that SDK to be zephyr-specific, so if the C library is built as part of that toolchain, it can (and should) understand the Zephyr syscall interface, defining the functions correctly for use in Zephyr. Similarly, a C library built as part of Zephyr should use the Zephyr syscall interface.

That is a reasonable long-term goal. Some work depends on this being resolved in the short-term.

Including hacks in Zephyr to work around libraries not designed for it is reasonable where you can't fix the library. In this case, the upstream projects would all be happy to accept Zephyr OS support.

Upstreamers welcome :-)

[cfriedt]

Currently doing a rework of this to separate it into a series of several easily-reviewable commits.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.