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

[Thomas Weißschuh]

On 2026-03-22 12:03:30+0100, Willy Tarreau wrote:
> 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).

What is the advantage of switching over to the nolibc-provided
implementation? The custom implementation would be good enough anyways.

(...)

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

That makes sense where you have to work with the external library in the
form it is provided to you by somebody else. nolibc should be vendored,
so you always know exactly what it supports. Or do you have existing
usecases where you detect nolibc features?

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

With the UAPI headers the detection makes slightly more sense.
On the other hand we try to be backwards-compatible to fairly old
versions.

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

I don't think it makes the code worse or really have anything against it
in general. I just don't really see the advantage. For glibc this makes
sense, as an application will have to do with the version that is
present during compilation and at runtime. For nolibc this doesn't
really happen. Or I might be missing something :-)

If we adopt that scheme it should not only cover the _sys_*() functions
but also the regular ones, no?


Thomas