The __nolibc_enosys() fallback is used when the UAPI headers do not
provide a certain syscall number or any possible fallback syscall.
This is either because the syscall definition is fairly new and nolibc
tries to be compatible with old UAPI headers or an architecture does not
support a syscall at all.
Many of these __nolibc_enosys() fallbacks have become unnecessary.
Either because the "new" syscalls or not so new anymore or real
fallbacks have been implemented in the meantime.

Unnecessary usages of __nolibc_enosys() as it is not obvious anymore if
a given function is really implemented on all architectures.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Thomas Weißschuh (7):
      tools/nolibc: remove __nolibc_enosys() fallback from time64-related functions
      tools/nolibc: remove __nolibc_enosys() fallback from *at() functions
      tools/nolibc: remove __nolibc_enosys() fallback from dup2()
      tools/nolibc: remove __nolibc_enosys() fallback from fork functions
      tools/nolibc: fold llseek fallback into lseek()
      kselftest/arm64: tpidr2: Switch to waitpid() over wait4()
      tools/nolibc: drop wait4() support

 tools/include/nolibc/poll.h                |  4 +-
 tools/include/nolibc/sys.h                 | 90 +++++++++---------------------
 tools/include/nolibc/sys/timerfd.h         |  8 +--
 tools/include/nolibc/sys/wait.h            | 17 ------
 tools/include/nolibc/time.h                |  8 +--
 tools/testing/selftests/arm64/abi/tpidr2.c |  6 +-
 6 files changed, 34 insertions(+), 99 deletions(-)
---
base-commit: 850047b19741490631855a475ccaa3ed29316039
change-id: 20250821-nolibc-enosys-2b2ec0b505ba

Best regards,
-- 
Thomas Weißschuh <linux@weissschuh.net>

Hi Thomas,

On Thu, Aug 21, 2025 at 05:40:31PM +0200, Thomas Weißschuh wrote:
> The __nolibc_enosys() fallback is used when the UAPI headers do not
> provide a certain syscall number or any possible fallback syscall.
> This is either because the syscall definition is fairly new and nolibc
> tries to be compatible with old UAPI headers or an architecture does not
> support a syscall at all.
> Many of these __nolibc_enosys() fallbacks have become unnecessary.
> Either because the "new" syscalls or not so new anymore or real
> fallbacks have been implemented in the meantime.
> 
> Unnecessary usages of __nolibc_enosys() as it is not obvious anymore if
> a given function is really implemented on all architectures.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

OK I reviewed it all and it's fine for me. Please note in patch 1's
commit message, s/where added/were added/ :-)

For the whole series:
  Acked-by: Willy Tarreau <w@1wt.eu>

Thanks,
Willy