On Sun, 3 Sept 2023 at 11:49, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Why _is_ glibc doing that thing?
Oh, I think I may see where the confusion may come from.
The glibc people found a "__NR_newfstatat", and thought it was a newer
version of 'stat', and didn't find any new versions of the basic
stat/fstat/lstat functions at all. So they thought that everything
else was implemented using that 'newfstatat()' entrypoint.
But on x86-64 (and most half-way newer architectures), the regular
__NR_stat *is* that "new" stat.
After all, it was only "new" in 1992, long before x86-64 even existed.
So maybe somebody noticed that "__NR_newfstatat" is the only system
call number that has that "new" in the stat name, and didn't realize
that that was just an odd naming thing for strange historical reasons.
The relevant system call numbers are
#define __NR_stat 4
#define __NR_fstat 5
#define __NR_lstat 6
#define __NR_newfstatat 262
#define __NR_statx 332
and the numbering very much is about when they were added.
And yes, that "new" in "newfstatat" is misleading, it's the same
'struct stat' as those stat/fstat/lstat system calls (but not the
'statx' one, that has 'struct statx', of course).
On x86-32, which has that extra decade of history, you end up with
#define __NR_oldstat 18
#define __NR_oldfstat 28
#define __NR_oldlstat 84
#define __NR_stat 106
#define __NR_lstat 107
#define __NR_fstat 108
#define __NR_stat64 195
#define __NR_lstat64 196
#define __NR_fstat64 197
#define __NR_fstatat64 300
#define __NR_statx 383
where 106-108 are those "new" stat calls. And then the stat64 ones
are the "new new" ones and the only version that was relevant by the
time we got the 'at()' version.
Linus
