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

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

Hi Thomas,

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.

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

Agreed.
 
> 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_*.

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

> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> 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@1wt.eu>

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.

Cheers,
Willy