On Wed, Jul 03, 2024 at 08:44:50PM GMT, Arnd Bergmann wrote:
> On Wed, Jul 3, 2024, at 19:40, Linus Torvalds wrote:
> > On Wed, 3 Jul 2024 at 10:30, Xi Ruoyao <xry111@xxxxxxxxxxx> wrote:
> >>
> >> struct stat64 {
> >>
> >> // ...
> >>
> >> int st_atime; /* Time of last access. */
> >
> > Oh wow. Shows just *how* long ago that was - and how long ago I looked
> > at 32-bit code. Because clearly, I was wrong.
> >
> > I guess it shows how nobody actually cares about 32-bit any more, at
> > least in the 2037 sense.
> >
> > The point stands, though - statx isn't a replacement for existing binaries.
>
> We had long discussions about adding another stat()/fstat()
> variant with 64-bit timestamps from 2012 to 2017, the result
> was that we mandated that a libc implementation with 64-bit
> time_t must only use statx() and not fall back to the time32
> syscalls on kernels that are new enough to have statx().
> This is both for architectures that were introduced after
> time64 support was added (riscv32 and the glibc port for
> arc), and for userspace builds that are explicitly using
> time64 syscalls only.
>
> That may have been a mistake in hindsight, or it may have
> been the right choice, but the thing is that if we now decide
> that 32-bit userspace can not rely on statx() to be available,
> then we need to introduce one or two new system calls.
I'm not sure we need to now pull the rug out from everyone now and I
don't think this was where the discussion was going. Any new
architecture will implement statx(). And for 32bit I think that's
entirely fine and we don't need to add even more variants just for this
case. I don't think we need to add newnewstat_promiseitsthelastone().
