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 <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260319-nolibc-namespacing-v1-1-33c22eaddb5e@weissschuh.net
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 <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260223-nolibc-namespacing-v1-1-52574ffebb2c@weissschuh.net
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 <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-7-c662992f75d7@weissschuh.net
Make sure to always use the 64-bit safe system calls
in preparation for 64-bit time_t on 32-bit architectures.
Also prevent issues on kernels which disable CONFIG_COMPAT_32BIT_TIME
and therefore don't provide the 32-bit system calls anymore.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-5-c662992f75d7@weissschuh.net
These implementations use the libc 'struct timeval' with system calls
which can lead to type mismatches. Currently this is fine, but will
break with upcoming changes to 'struct timeval'.
If the structure needs to be converted anyways, the implementations
based on pselect can be used for all architectures. This simplifies the
logic.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-3-c662992f75d7@weissschuh.net
Modern programs tend to include sys/select.h to get FD_SET() and
FD_CLR() definitions as well as struct fd_set, but in our case it
didn't exist.
The definitions were moved from types.h to sys/select.h, which is
now included from nolibc.h, and the sys_select() definition moved
there as well from sys.h.
Signed-off-by: Willy Tarreau <w@1wt.eu>
[Thomas: adapt to current -next branch]
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
