Re: [PATCH] tools/nolibc: rename sys_foo() functions to _sys_foo()

[Thomas Weißschuh]

On 2026-03-22 10:06:42+0100, Willy Tarreau wrote:
> On Thu, Mar 19, 2026 at 05:20:17PM +0100, Thomas Weißschuh wrote:
> > 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.
> 
> Yes but on the other hand it might implement it when missing the one
> offered by the libc.

I don't really get this sentence. Do you refer to the '#ifdef sys_foo'
as you mention below?

(...)

> > 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.
> 
> I also checked in my local stuff (preinit, watchdog daemon etc) and
> didn't find any user of sys_*.

Nice!

> > These conflicts happen when compiling some of the kernel selftests
> > with nolibc.
> 
> You mean some of the syscall entry points ? If so, I'm seeing one
> exception of _sys_rt_sigreturn(), not convinced it could be an issue
> though.

Not the syscall entrypoints, these are internal to the kernel.
Some selftests bypass libc (for various, legitimate reasons) and
directly call the syscalls. They tend to name their wrappers
'sys_foo()'.

See for example these:
* tools/testing/selftests/vDSO/vdso_test_correctness.c
* tools/testing/selftests/bpf/bpf_util.h
* tools/testing/selftests/bpf/task_local_storage_helpers.h
* tools/testing/selftests/rseq/param_test.c

> > Signed-off-by: Thomas Weißschuh <linux@xxxxxxxxxxxxxx>
> > ---
> > I am not really thrilled about breaking these names.
> > But every other option seems to be horribly to maintain
> > or will break sooner or later anyways.
> > Any ideas?
> 
> I think your approach is reasonable for the reasons you explained. Yes we
> do want to continue to export these, and they're not supposed to be spread
> all over application code, so changes if any should be very limited. So:
> 
>   Acked-by: Willy Tarreau <w@xxxxxx>

Thanks! And pushed to the git tree.

> On a related topic, I've been thinking several times about how to discover
> support or not of a syscall in nolibc by the application, especially since
> the lib improves fast and applications might not want to wait for it to
> support a new syscall, and end up with their own as you suggested above.
> Maybe this _sys_foo thing could be the opportunity for us to generalize
> the systematic addition of:
> 
>   #define _sys_foo _sys_foo
> 
> before every definition, so that application can simply use #ifndef to
> define their own local version. There's no emergency, it's been that way
> for years, I'm sharing it just as food for thought.

I am not sure about that.

In the most common case, where the version of nolibc is locked,
the local version would either be used all the time or never.
So any ifdeffery would only make the code harder to read.
Even if a user really needs to handle different versions of nolibc,
in my opinion they should just always use their custom code to make
sure to keep the behavior predictable.


Thomas