[PATCH] checksyscalls: Unconditionally ignore fstat{,at}64

[PATCH] checksyscalls: Unconditionally ignore fstat{,at}64

[Palmer Dabbelt]

From: Palmer Dabbelt <palmerdabbelt@google.com>

These can be replaced by statx().  Since rv32 has a 64-bit time_t we
just never ended up with them in the first place.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
Happy to take this through the RISC-V tree, as it's fixing a build warning
(that's being promoted to an error for me, not sure why).  I'm just not all
that familiar with how this one works.

Arnd suggested putting these here, but not exactly doing it this way.
---
 scripts/checksyscalls.sh | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh
index fd9777f63f14..9dbab13329fa 100755
--- a/scripts/checksyscalls.sh
+++ b/scripts/checksyscalls.sh
@@ -82,10 +82,8 @@ cat << EOF
 #define __IGNORE_truncate64
 #define __IGNORE_stat64
 #define __IGNORE_lstat64
-#define __IGNORE_fstat64
 #define __IGNORE_fcntl64
 #define __IGNORE_fadvise64_64
-#define __IGNORE_fstatat64
 #define __IGNORE_fstatfs64
 #define __IGNORE_statfs64
 #define __IGNORE_llseek
@@ -253,6 +251,10 @@ cat << EOF
 #define __IGNORE_getpmsg
 #define __IGNORE_putpmsg
 #define __IGNORE_vserver
+
+/* 64-bit ports never needed these, and new 32-bit ports can use statx */
+#define __IGNORE_fstat64
+#define __IGNORE_fstatat64
 EOF
 }
 
-- 
2.33.0.800.g4c38ced690-goog

Re: [PATCH] checksyscalls: Unconditionally ignore fstat{,at}64

[Arnd Bergmann]

On Sun, Oct 3, 2021 at 2:56 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> From: Palmer Dabbelt <palmerdabbelt@google.com>
>
> These can be replaced by statx().  Since rv32 has a 64-bit time_t we
> just never ended up with them in the first place.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

> Happy to take this through the RISC-V tree, as it's fixing a build warning
> (that's being promoted to an error for me, not sure why).  I'm just not all
> that familiar with how this one works.
>
> Arnd suggested putting these here, but not exactly doing it this way.

Merging it through your tree sounds good.