Re: [PATCH 1/7] tools/nolibc: also handle _llseek system call

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

On Sat, Apr 18, 2026 at 05:03:40PM +0100, David Laight wrote:
> On Sat, 18 Apr 2026 13:56:46 +0200
> Thomas Weißschuh <linux@weissschuh.net> wrote:
> 
> > Apr 18, 2026 13:23:43 David Laight <david.laight.linux@gmail.com>:
> > 
> > > On Sat, 18 Apr 2026 12:19:56 +0200
> > > Thomas Weißschuh <linux@weissschuh.net> wrote:
> > >  
> > >> On some architectures the llseek system call contains a leading
> > >> underscore. Also check for that one and prefer it over the lseek system
> > >> call as it is necessary for 64-bit offset handling.
> > >>  
> > > ...  
> > >> +#if defined(__NR_llseek)
> > >> +   nr_llseek = __NR_llseek;
> > >> +#else
> > >> +   nr_llseek = __NR__llseek;
> > >> +#endif  
> > >
> > > Is that test the right way around?
> > > The commit messages says prefer _llseek, but that seems to prefer llseek.  
> > 
> > Yes. lseek is the ifdef case below.
> > Here we have _llseek and llseek.
> > lseek always exists, but may no handle 64 bit offsets.
> > Only one of llseek and _llseek exists
> > for one given architecture.
> 
> Ok, the fact that you said 'prefer' made me think that both might
> sometimes exist.

While I'm totally fine with the patch, I agree with David that the commit
message is misleading, as what the code does is to check for llseek and
fall back to _llseek when it is not defined, and not prefer the second
over the former.

The commit message should rather say something like:

  On some architectures the llseek system call contains a leading
  underscore. Fall back to it when llseek is not available and use it
  for the lseek system call as it is necessary for 64-bit offset handling.

But overall it's an ack from me.

Acked-by: Willy Tarreau <w@1wt.eu>

Thanks!
Willy