kernel/git/stable/linux.git/tools/include/nolibc/sys.h, branch master

tools/nolibc: add a helper to split a 64-bit argument into 32-bit halves

2026-05-24T21:57:59+00:00

On 32-bit architectures some system calls require a single 64-bit argument to be passed as two 32-bit halves. Add a helper to easily split such arguments. This works on little and bit endian. Signed-off-by: Daniel Palmer Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260521-nolibc-ftruncate-v1-2-5384a83b2402@weissschuh.net Signed-off-by: Thomas Weißschuh

tools/nolibc: cast pointers returned from system calls through integers

2026-04-27T18:08:54+00:00

Currently all system call wrappers return 'long' integers which can be directly cast to 'void *' if the returned value is actually a pointer. An upcoming change will change the system call wrappers to sometimes return 'long long' which can not be cast to a pointer directly. Add explicit cast through 'long' to prepare for this. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-3-b91f0775bac3@weissschuh.net

tools/nolibc: also handle _llseek system call

2026-04-27T17:45:25+00:00

On some architectures the llseek system call contains a leading underscore. Treat it the same way as llseek and prefer it over the plain lseek system call as is necessary for 64-bit offset handling. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260418-nolibc-largefile-v1-1-b91f0775bac3@weissschuh.net

tools/nolibc: make __nolibc_enosys() a compile time error

2026-04-27T07:00:52+00:00

Functions which are known at compile-time to result in ENOSYS can be surprising to the user. For example using old UAPI headers might mean that stat() will always fail although the kernel would have the system call available at runtime. Nowadays __nolibc_enosys() should never be called for normal applications. Switch the silent ENOSYS return into a compile-time error, so the user is aware about the issue. Prefer the 'error' attribute as it provides the best diagnostics. If the users defines NOLIBC_COMPILE_TIME_ENOSYS the old, silent fallback is kept. Also add a test which validates that the error can be optimized away. Reported-by: Willy Tarreau Closes: https://lore.kernel.org/lkml/acizRIq2xrFUNHNS@1wt.eu/ Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260404-nolibc-enosys-v1-1-e0aba47bdee4@weissschuh.net

tools/nolibc: rename sys_foo() functions to _sys_foo()

2026-03-22T10:03:59+00:00

The sys_foo() naming scheme used by the syscall wrappers may collide with application symbols. Especially as 'sys_' is an obvious naming scheme an application may choose for its own custom systemcall wrappers. Avoid these conflicts by using an leading underscore which moves the names into the implementation's namespace. This naming scheme was chosen over a '__nolibc_' prefix, as these functions are not an implementation detail but a documented interface meant to be used by applications. While this may break some existing users, adapting them should be straightforward. Given that nolibc is most-likely vendored, no unexpected breakage should happen. No in-tree users are affected. These conflicts happen when compiling some of the kernel selftests with nolibc. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260319-nolibc-namespacing-v1-1-33c22eaddb5e@weissschuh.net

tools/nolibc: rename my_syscallX() to __nolibc_syscallX()

2026-02-25T07:21:17+00:00

The naming convention of the my_syscallX() macros is a bit unfortunate. They may conflict with application code and the name is very generic. Switch to __nolibc_syscallX(). The leading underscores place the symbols in the implementation-defined namespace, avoiding conflicting names. It is also clearer that these are non-standard extensions from nolibc. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Link: https://patch.msgid.link/20260223-nolibc-namespacing-v1-1-52574ffebb2c@weissschuh.net

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

2026-01-06T11:08:10+00:00

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

tools/nolibc: remove now superfluous overflow check in llseek

2025-11-20T18:47:04+00:00

As off_t is now always 64-bit wide this overflow can not happen anymore, remove the check. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau Reviewed-by: Arnd Bergmann

tools/nolibc: prefer the llseek syscall

2025-11-20T18:46:52+00:00

Make sure to always use the 64-bit safe system call in preparation for 64-bit off_t on 32 bit architectures. Signed-off-by: Thomas Weißschuh Acked-by: Willy Tarreau

tools/nolibc: handle 64-bit off_t for llseek

2025-11-20T18:46:45+00:00

Correctly handle 64-bit off_t values in preparation for 64-bit off_t on 32-bit architectures. Signed-off-by: Thomas Weißschuh Acked-by: Arnd Bergmann Acked-by: Willy Tarreau