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

[Willy Tarreau <w@1wt.eu>]

On Sun, Mar 22, 2026 at 11:43:56AM +0100, Thomas Weißschuh wrote:
> 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?

Ah no, but rereading my message shows me it was not really parsable :-)
I meant that some applications missing a syscall in nolibc (and detecting
this miss via any method) could decide to implement their own equivalent
for the time it takes to integrate the feature into nolibc, and thus it
can make sense that they call their feature sys_foo like we do, so that
their sys_foo is basically the same as ours (i.e. they really just have
to detect the conflict one way or another but that's all).

> > > 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.

That's why it surprised me ;-)

> 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

Ah OK! That totally makes sense.

> Thanks! And pushed to the git tree.

Thank you!

> > 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.

In fact it's not about handling different versions, it's really about
working around what's missing. I face this every day as a userland
developer. As soon as you depend on a lib, you figure something is
missing, and you cannot stop your project because of this. So the
right thing to do is to implement what you're missing in a mostly
discoverable way, and the try to upstream your work into the lib that
was missing the feature.

Inside the kernel, this problem is less visible because it's the same
repository, so anyone working on their selftest etc can also directly
commit into the nolibc subdir as well. When you're using code outside
it's totally different, as you have less control over the selection of
kernel headers version, hence nolibc version.

I personally don't think that a single define in front of each syscall
definition will make the code harder to read. It can be argued that glibc
doesn't offer this and that the user application will have to compose with
all of this, however glibc offers lots more stuff than we do, and users
rely on its version to guess whether or not something is present, which
is something we don't really have.

Willy