| 2eb64b93 | 05-Apr-2026 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: add the _syscall() macro
The standard syscall() function or macro uses the libc return value convention. Errors returned from the kernel as negative values are stored in errno and -1 i
tools/nolibc: add the _syscall() macro
The standard syscall() function or macro uses the libc return value convention. Errors returned from the kernel as negative values are stored in errno and -1 is returned. Users who want to avoid using errno don't have a way to call raw syscalls and check the returned error.
Add a new macro _syscall() which works like the standard syscall() but passes through the return value from the kernel unchanged. The naming scheme and return values match the named _sys_foo() system call wrappers already part of nolibc.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260405-nolibc-syscall-v1-3-e5b12bc63211@weissschuh.net
show more ...
|
| 022bbb5a | 05-Apr-2026 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: move the call to __sysret() into syscall()
__sysret() transforms the return value from the kernel into the libc return value convention. There is no reason for it to be called in the m
tools/nolibc: move the call to __sysret() into syscall()
__sysret() transforms the return value from the kernel into the libc return value convention. There is no reason for it to be called in the middle of the internals of the syscall() implementation macros.
Move the call up, directly into syscall(), to make the code simpler.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260405-nolibc-syscall-v1-2-e5b12bc63211@weissschuh.net
show more ...
|
| 867fb336 | 04-Apr-2026 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: use makedev() in fstatat()
fstatat() contains two open-coded copies of makedev() to handle minor numbers >= 256. Now that the regular makedev() handles both large minor and major numbe
tools/nolibc: use makedev() in fstatat()
fstatat() contains two open-coded copies of makedev() to handle minor numbers >= 256. Now that the regular makedev() handles both large minor and major numbers correctly use the common function.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260404-nolibc-makedev-v2-6-456a429bf60c@weissschuh.net
show more ...
|
| 70091ead | 04-Apr-2026 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: move the logic of makedev() and friends into functions
Functions make it easier to keep the input and output types straight and avoid duplicate evaluations of their arguments.
Also th
tools/nolibc: move the logic of makedev() and friends into functions
Functions make it easier to keep the input and output types straight and avoid duplicate evaluations of their arguments.
Also these functions will become a bit more complex to handle full 64-bit 'dev_t' which is easier to read in a function.
Still stay compatible with code which expects these to be macros.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260404-nolibc-makedev-v2-3-456a429bf60c@weissschuh.net
show more ...
|
| f3ed9326 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
selftests/nolibc: add static assertions around time types handling
The nolibc system call wrappers expect the libc types to be compatible to the kernel types.
Make sure these expectations hold at c
selftests/nolibc: add static assertions around time types handling
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 <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-14-c662992f75d7@weissschuh.net
show more ...
|
| 6c9be905 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: remove time conversions
Now that 'struct timespec' and 'struct __kernel_timespec' are compatible, the conversions are not necessary anymore. The same holds true for 'struct itimerspec'
tools/nolibc: remove time conversions
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 <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-11-c662992f75d7@weissschuh.net
show more ...
|
| 47c17d97 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc/select: avoid libgcc 64-bit multiplications
timeval::tv_usec is going to be 64-bit wide even on 32-bit architectures. As not all architectures support 64-bit multiplications instruction
tools/nolibc/select: avoid libgcc 64-bit multiplications
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
show more ...
|
| 7efd15d2 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc/gettimeofday: avoid libgcc 64-bit divisions
timespec::tv_nsec is going to be 64-bit wide even on 32-bit architectures. As not all architectures support 64-bit division instructions, cal
tools/nolibc/gettimeofday: avoid libgcc 64-bit divisions
timespec::tv_nsec is going to be 64-bit wide even on 32-bit architectures. As not all architectures support 64-bit division instructions, calls to libgcc (__divdi3()) may be emitted by the compiler which are not provided by nolibc.
As tv_nsec is guaranteed to always fit into an uint32_t, perform a 32-bit division instead.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20251220-nolibc-uapi-types-v3-6-c662992f75d7@weissschuh.net
show more ...
|
| ba7fd038 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: prefer explicit 64-bit time-related system calls
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
tools/nolibc: prefer explicit 64-bit time-related system calls
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
show more ...
|
| b8f4f5d1 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc/time: drop invocation of gettimeofday system call
This invocation uses libc types with a system call. While this works now, upcoming changes to 'struct timeval' would require type conve
tools/nolibc/time: drop invocation of gettimeofday system call
This invocation uses libc types with a system call. While this works now, upcoming changes to 'struct timeval' would require type conversions. If types are converted anyways, the clock_gettime() based fallback can be used everywhere, simplifying the code.
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-4-c662992f75d7@weissschuh.net
show more ...
|
| 668e4373 | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc/select: drop non-pselect based implementations
These implementations use the libc 'struct timeval' with system calls which can lead to type mismatches. Currently this is fine, but will
tools/nolibc/select: drop non-pselect based implementations
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
show more ...
|
| f675e35d | 20-Dec-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc/poll: use kernel types for system call invocations
The system calls expect 'struct __kernel_old_timespec'. While currently 'struct __kernel_old_timespec' and 'struct timespec' are compa
tools/nolibc/poll: use kernel types for system call invocations
The system calls expect 'struct __kernel_old_timespec'. While currently 'struct __kernel_old_timespec' and 'struct timespec' are compatible, this is confusing. Especially as future patches will change the definition of 'struct timespec'.
Use the correct kernel type instead.
Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/lkml/fbca1d3e-12e4-4c4e-8091-87464035fe39@app.fastmail.com/ 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-1-c662992f75d7@weissschuh.net
show more ...
|
| 2d848295 | 09-Nov-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: avoid using plain integer as NULL pointer
While an integer zero is a valid NULL pointer as per the C standard, sparse will complain about it.
Use explicit NULL pointers instead.
Repo
tools/nolibc: avoid using plain integer as NULL pointer
While an integer zero is a valid NULL pointer as per the C standard, sparse will complain about it.
Use explicit NULL pointers instead.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202509261452.g5peaXCc-lkp@intel.com/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu>
show more ...
|
| 10f407c6 | 02-Nov-2025 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: provide the portable sys/select.h
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
tools/nolibc: provide the portable sys/select.h
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>
show more ...
|
| 089c0a98 | 28-Oct-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: remove outdated comment about __sysret() in mmap()
Since commit fb01ff635efd ("tools/nolibc: keep brk(), sbrk(), mmap() away from __sysret()") the implementation of mmap() does not use
tools/nolibc: remove outdated comment about __sysret() in mmap()
Since commit fb01ff635efd ("tools/nolibc: keep brk(), sbrk(), mmap() away from __sysret()") the implementation of mmap() does not use the __sysret() macro anymore.
Remove the outdated comment.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
show more ...
|
| 4c2ef951 | 21-Aug-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: drop wait4() support
Not all architectures implement the wait4() syscall. It can be implemented in terms of the waitid() syscall, but that would require some rework of the other wait-r
tools/nolibc: drop wait4() support
Not all architectures implement the wait4() syscall. It can be implemented in terms of the waitid() syscall, but that would require some rework of the other wait-related functions in wait.h.
As wait4() is non-standard and deprecated, remove it.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20250821-nolibc-enosys-v1-7-4b63f2caaa89@weissschuh.net
show more ...
|
| e6366101 | 21-Aug-2025 |
Thomas Weißschuh <linux@weissschuh.net> |
tools/nolibc: remove __nolibc_enosys() fallback from time64-related functions
These fallbacks where added when no explicit fallbacks for time64 was implemented. Now that these fallbacks are in place
tools/nolibc: remove __nolibc_enosys() fallback from time64-related functions
These fallbacks where added when no explicit fallbacks for time64 was implemented. Now that these fallbacks are in place, the additional fallback to __nolibc_enosys() is superfluous.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20250821-nolibc-enosys-v1-1-4b63f2caaa89@weissschuh.net
show more ...
|