linux/tools/include/nolibc, branch master

tools/nolibc: Add fseek() to stdio.h

2026-01-11T11:47:47Z

A very basic wrapper around lseek() that implements fseek(). Signed-off-by: Daniel Palmer Link: https://patch.msgid.link/20260105023629.1502801-3-daniel@thingy.jp Signed-off-by: Thomas Weißschuh

tools/nolibc: Add fread() to stdio.h

2026-01-11T11:47:47Z

Add a very basic version of fread() like we already have for fwrite(). Signed-off-by: Daniel Palmer Link: https://patch.msgid.link/20260105023629.1502801-2-daniel@thingy.jp Signed-off-by: Thomas Weißschuh

tools/nolibc: align sys_vfork() with sys_fork()

2026-01-06T11:08:10Z

Currently the generic variants of sys_fork() and sys_vfork() differ in both they precedence of used system calls and the usage of sys_clone() vs sys_clone3(). While the interface of clone3() in sys_vfork() is more consistent over different architectures, qemu-user does not support it, making testing harder. We already handle the different clone() interfaces for sys_fork() in the architecture-specific headers, and can do so also for sys_vfork(). In fact SPARC already has such handling and only s390 is currently missing. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260104-nolibc-vfork-v1-1-a63464b9e4e6@weissschuh.net

selftests/nolibc: add static assertions around time types handling

2026-01-06T11:08:08Z

The nolibc system call wrappers expect the libc types to be compatible to the kernel types. Make sure these expectations hold at compile-time. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-14-c662992f75d7@weissschuh.net

tools/nolibc: add __nolibc_static_assert()

2026-01-06T11:08:08Z

Add a wrapper for _Static_assert() to use within nolibc. While _Static_assert() itself was only standardized in C11, in GCC and clang dialects it is also available in older standards. Link: https://lore.kernel.org/lkml/20251203192330.GA12995@1wt.eu/ Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-13-c662992f75d7@weissschuh.net

tools/nolibc: add compiler version detection macros

2026-01-06T11:08:07Z

Some upcoming logic needs to depend on the version of GCC or clang. Add some helper macros to keep the conditionals readable. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-12-c662992f75d7@weissschuh.net

tools/nolibc: remove time conversions

2026-01-06T11:08:06Z

Now that 'struct timespec' and 'struct __kernel_timespec' are compatible, the conversions are not necessary anymore. The same holds true for 'struct itimerspec' and 'struct __kernel_itimerspec'. Remove the conversions. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-11-c662992f75d7@weissschuh.net

tools/nolibc: always use 64-bit time types

2026-01-04T09:29:03Z

32-bit time types will stop working in 2038. Switch to 64-bit time types everywhere. Suggested-by: Arnd Bergmann Link: https://lore.kernel.org/lkml/cec27d94-c99d-4c57-9a12-275ea663dda8@app.fastmail.com/ Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-9-c662992f75d7@weissschuh.net

tools/nolibc: use custom structs timespec and timeval

2026-01-04T09:29:02Z

A custom 'struct timespec' and 'struct timeval' will be necessary for 64-bit time types on 32-bit architectures. will define other time-related types in terms of the custom 'struct timespec'. Add custom struct definitions which for now mirror exactly the ones from the UAPI headers, but provide the foundation for further changes. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-8-c662992f75d7@weissschuh.net

tools/nolibc/select: avoid libgcc 64-bit multiplications

2026-01-04T09:29:02Z

timeval::tv_usec is going to be 64-bit wide even on 32-bit architectures. As not all architectures support 64-bit multiplications instructions, calls to libgcc (__multi3()) may be emitted by the compiler which are not provided by nolibc. As tv_usec and tv_nsec are guaranteed to always fit into an uint32_t, perform a 32-bit multiplication instead. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-7-c662992f75d7@weissschuh.net