[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi=So-PDxjetjN6bs3878rOYpz8EQgU+JvrHmLF_0hgBw@mail.gmail.com>
Date: Wed, 3 Jul 2024 12:18:24 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Xi Ruoyao <xry111@...111.site>, libc-alpha@...rceware.org,
"Andreas K. Huettel" <dilfridge@...too.org>, Arnd Bergmann <arnd@...db.de>,
Huacai Chen <chenhuacai@...nel.org>, Mateusz Guzik <mjguzik@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, io-uring@...r.kernel.org,
Jens Axboe <axboe@...nel.dk>, loongarch@...ts.linux.dev
Subject: Re: [PATCH 2/2] vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)
On Wed, 3 Jul 2024 at 12:00, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Well, I do think that a *new* architecture should indeed add all of
> those, but make the 'struct stat' for all of them be the same.
Just to clarify: by "all of those" I don't mean all the
stat64/oldstat/newstat variants that we have for compatibility with
older ABI's, but all the "calling conventions" variants.
IOW, all of stat/lstat/fstat and statx should exist as separate system
calls, and libc shouldn't have to rewrite arguments to make one into
another.
(And yes, things like 'strace()' and friends should show what the app
did, not what glibc had to rewrite things as, which is a private pet
peeve of mine)
Linus
Powered by blists - more mailing lists