Re: [PATCH v3 01/11] tools/nolibc: remove the old sys_stat support

[Zhangjin Wu]

> Hi Zhangjin,
> 
> On Wed, Jul 12, 2023 at 05:16:34PM +0800, Zhangjin Wu wrote:
> > __NR_statx has been added from v4.10:
> > 
> >     commit a528d35e8bfc ("statx: Add a system call to make enhanced file info available")
> > 
> > It has been supported by all of the platforms since at least from v4.20
> > and glibc 2.28.
> > 
> > Let's remove the old arch related and dependent sys_stat support
> > completely.
> > 
> > This is friendly to the future new architecture porting.
> 
> As I previously said, I'd like that we at least preserve compatibility
> with supported stable branches. 4.14 and 4.19 are still supported, so
> does this mean that if I rebuild my preinit against the updated nolibc
> it will fail to boot on such older systems for the archs that we support?
>
> Because if it means that in order to support all currently active
> kernels, one must only build from an older copy of the lib, that becomes
> a disservice to its development and usage. Thus if you checked that aarch64,
> arm, i386, mips, riscv, s390 and x86_64 had already adopted statx by 4.14,
> then I'm fine and we can drop stat(), but then it must be mentioned in
> the commit message, because here it's not explicit.
>

Yeah, we used 'git blame' before and found the last related change is
v4.20, but it is not really the first change.

Just read the statx manpage again:

    https://man7.org/linux/man-pages/man2/statx.2.html

It shows something about "Linux 4.11, glibc 2.28.

And 'git grep' shows it is true:

    $ git grep -r statx v4.11 arch/ include/uapi/asm-generic/unistd.h | grep -E "aarch64|arm|mips|s390|x86|:include/uapi"
    v4.11:arch/arm/tools/syscall.tbl:397	common	statx			sys_statx
    v4.11:arch/arm64/include/asm/unistd32.h:#define __NR_statx 397
    v4.11:arch/arm64/include/asm/unistd32.h:__SYSCALL(__NR_statx, sys_statx)
    v4.11:arch/mips/include/uapi/asm/unistd.h:#define __NR_statx			(__NR_Linux + 366)
    v4.11:arch/mips/include/uapi/asm/unistd.h:#define __NR_statx			(__NR_Linux + 326)
    v4.11:arch/mips/include/uapi/asm/unistd.h:#define __NR_statx			(__NR_Linux + 330)
    v4.11:arch/mips/kernel/scall32-o32.S:	PTR	sys_statx
    v4.11:arch/mips/kernel/scall64-64.S:	PTR	sys_statx
    v4.11:arch/mips/kernel/scall64-n32.S:	PTR	sys_statx			/* 6330 */
    v4.11:arch/mips/kernel/scall64-o32.S:	PTR	sys_statx
    v4.11:arch/s390/include/uapi/asm/unistd.h:#define __NR_statx		379
    v4.11:arch/s390/kernel/compat_wrapper.c:COMPAT_SYSCALL_WRAP5(statx, int, dfd, const char __user *, path, unsigned, flags, unsigned, mask, struct statx __user *, buffer);
    v4.11:arch/s390/kernel/syscalls.S:SYSCALL(sys_statx,compat_sys_statx)
    v4.11:arch/x86/entry/syscalls/syscall_32.tbl:383	i386	statx			sys_statx
    v4.11:arch/x86/entry/syscalls/syscall_64.tbl:332	common	statx			sys_statx
    v4.11:include/uapi/asm-generic/unistd.h:#define __NR_statx 291
    v4.11:include/uapi/asm-generic/unistd.h:__SYSCALL(__NR_statx,     sys_statx)

both riscv and loongarch use the generic unistd.h, so, all of our
supported archs should work as-is. riscv itself is added from v4.15,
loongarch itself is added from v5.19.

The powerpc we plan to support is from v4.11:

    $ git grep -r statx v4.11 arch/powerpc/
    v4.11:arch/powerpc/include/asm/systbl.h:SYSCALL(statx)
    v4.11:arch/powerpc/include/uapi/asm/unistd.h:#define __NR_statx         383

So, let's simply correct the commit message (the old v4.10 has a wrong -1
offset, I wrongly used 'git show a528d35e8bfc:Makefile' before).

    sys_statx has been supported from Linux v4.11 and glibc 2.28:

        $ git grep -r statx v4.11 arch/ include/uapi/asm-generic/unistd.h

    Both riscv (firstly added from v4.15) and loongarch (firstly added from
    v5.19) use the generic unistd.h, the others are supported from arch/.
 
    Let's remove the old arch related and dependent sys_stat support
    completely.

    Since the current oldest stable branch is v4.14, so, using statx
    instead of sys_stat preserves compatibility with all of the
    supported stable branches.
    
    This is friendly to the future new architecture porting.

Best regards,
Zhangjin

> Thanks!
> Willy