public inbox for [email protected]
 help / color / mirror / Atom feed
From: Linus Torvalds <[email protected]>
To: Xi Ruoyao <[email protected]>
Cc: Christian Brauner <[email protected]>,
	[email protected],
	 "Andreas K. Huettel" <[email protected]>,
	Arnd Bergmann <[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, 3 Jul 2024 10:09:15 -0700	[thread overview]
Message-ID: <CAHk-=wif5KJEdvZZfTVX=WjOOK7OqoPwYng6n-uu=VeYUpZysQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Wed, 3 Jul 2024 at 09:54, Xi Ruoyao <[email protected]> wrote:
>
> > Honestly, 'statx' is disgusting. I don't understand why anybody pushes
> > that thing that nobody actually uses or cares about.
>
> Hmm why it was added in the first place then?  Why not just NAK it?

There are valid uses of statx - they are just VERY very few and far between.

For example, if you want the "change cookie" or any number of other
special things that aren't standard, you have to use statx.

But _normal_ programs will never do that. It's unportable, and it
really is a specialty interface.

Pushing 'statx' as a replacement for 'stat' is just crazy. It's a
different thing. It's not a "better" thing. It's an extension, yes,
but "extension" doesn't mean "better".

That's true when it was mis-designed in certain ways that we now have
to fix up, but PARTICULARLY true when it's nonstandard and no other OS
has it.

> And should we add stat_time64, fstat_time64, and fstatat_time64 to stop
> using statx on 32-bit platforms too as it's disgusting?

We already have 'stat64' for 32-bit platforms. We have had it for over
25 years - it predates not only the kernel git tree, it predates the
BK tree too.

I think stat64 was introduced in 2.3.34. That is literally last century.

Anybody who tries to make this about 2037 is being actively dishonest.

Why are people even discussing this pointless thing?

            Linus

  reply	other threads:[~2024-07-03 17:09 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 [this message]
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
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='CAHk-=wif5KJEdvZZfTVX=WjOOK7OqoPwYng6n-uu=VeYUpZysQ@mail.gmail.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