public inbox for [email protected]
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <[email protected]>
To: "Linus Torvalds" <[email protected]>,
	"Xi Ruoyao" <[email protected]>
Cc: "Christian Brauner" <[email protected]>,
	"Xi Ruoyao" <[email protected]>,
	"Andreas K Huettel" <[email protected]>,
	"Huacai Chen" <[email protected]>,
	"Mateusz Guzik" <[email protected]>,
	"Alexander Viro" <[email protected]>,
	"Jan Kara" <[email protected]>,
	[email protected], [email protected],
	[email protected], "Jens Axboe" <[email protected]>,
	[email protected]
Subject: Re: [PATCH 2/2] vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)
Date: Wed, 03 Jul 2024 20:44:50 +0200	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHk-=wjH3F1jTVfADgo0tAnYStuaUZLvz+1NkmtM-TqiuubWcw@mail.gmail.com>

On Wed, Jul 3, 2024, at 19:40, Linus Torvalds wrote:
> On Wed, 3 Jul 2024 at 10:30, Xi Ruoyao <[email protected]> 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.

    Arnd

  parent reply	other threads:[~2024-07-03 18:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25 11:00 [PATCH 0/2] statx NULL path support Mateusz Guzik
2024-06-25 11:00 ` [PATCH 1/2] vfs: add CLASS fd_raw Mateusz Guzik
2024-06-25 12:22   ` Xi Ruoyao
2024-06-25 13:13     ` Mateusz Guzik
2024-06-25 11:00 ` [PATCH 2/2] vfs: support statx(..., NULL, AT_EMPTY_PATH, ...) Mateusz Guzik
2024-06-25 13:24   ` Xi Ruoyao
2024-06-25 13:28     ` Xi Ruoyao
2024-06-25 13:28     ` Mateusz Guzik
2024-06-25 14:09   ` Huacai Chen
2024-06-25 14:58     ` Xi Ruoyao
2024-06-30  1:40       ` Huacai Chen
2024-06-30  2:39         ` Xi Ruoyao
2024-06-30 13:18           ` Huacai Chen
2024-07-01 11:59           ` Arnd Bergmann
2024-07-02 15:36             ` Huacai Chen
2024-07-02 17:06               ` Arnd Bergmann
2024-07-03  4:30                 ` Huacai Chen
2024-07-03  8:45                 ` Christian Brauner
2024-07-03  9:35                   ` Huacai Chen
2024-07-03 10:07                     ` Xi Ruoyao
2024-07-03 16:31                   ` Linus Torvalds
2024-07-03 16:54                     ` Xi Ruoyao
2024-07-03 17:09                       ` Linus Torvalds
2024-07-03 17:30                         ` Xi Ruoyao
2024-07-03 17:40                           ` Linus Torvalds
2024-07-03 17:54                             ` Linus Torvalds
2024-07-03 18:14                               ` Christian Brauner
2024-07-03 18:39                                 ` Christian Brauner
2024-07-03 19:00                                 ` Linus Torvalds
2024-07-03 19:18                                   ` Linus Torvalds
2024-07-03 18:48                               ` Xi Ruoyao
2024-07-03 19:05                                 ` Linus Torvalds
2024-07-03 19:33                                   ` Christian Brauner
2024-07-03 19:52                                     ` Linus Torvalds
2024-07-03 18:44                             ` Arnd Bergmann [this message]
2024-07-03 19:55                               ` Christian Brauner
2024-07-03 17:11                       ` Xi Ruoyao
2024-07-04  2:38                       ` Huacai Chen
2024-07-04  3:23                         ` Xi Ruoyao
2024-07-04  4:14                           ` Xi Ruoyao
2024-07-04  5:55                       ` Florian Weimer
2024-07-04  6:02                         ` Xi Ruoyao
2024-07-01  4:38 ` [PATCH 0/2] statx NULL path support Christoph Hellwig
2024-07-01  6:46   ` Xi Ruoyao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a30ac1fe-07ac-4b09-9ede-c9360a34a103@app.fastmail.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox