Re: [RFC PATCH] asm-generic: Unify uapi bitsperlong.h
On Fri, 2023-06-09 at 14:50 +0800, Tiezhu Yang wrote: /* snip */ > > > > In musl, the documentation states that at least gcc-3.4 or > > > > clang-3.2 are required, which probably predate the > > > > __SIZEOF_LONG__ macro. Indeed, I've digged some history and __SIZEOF_LONG__ was added into GCC- 4.3 (in 2008). And I didn't realize the bitsperlong.h in tools directory is a copy from uapi. > > > > On the other hand, musl was only > > > > released in 2011, and building musl itself explicitly > > > > does not require kernel uapi headers, so this may not > > > > be too critical. > Only arm64, riscv and loongarch belong to the newer architectures > which are related with this change, I am not sure it is necessary > to "unify" uapi bitsperlong.h for them. At least it will stop the engineers working on "the next architecture" from adding an unneeded bitsperlong.h :). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [RFC PATCH] asm-generic: Unify uapi bitsperlong.h
On 06/08/2023 08:56 PM, Arnd Bergmann wrote: On Thu, Jun 8, 2023, at 09:04, Tiezhu Yang wrote: On 05/09/2023 05:37 PM, Arnd Bergmann wrote: On Tue, May 9, 2023, at 09:05, Tiezhu Yang wrote: I think we are completely safe on the architectures that were added since the linux-3.x days (arm64, riscv, csky, openrisc, loongarch, nios2, and hexagon), but for the older ones there is a regression risk. Especially on targets that are not that actively maintained (sparc, alpha, ia64, sh, ...) there is a good chance that users are stuck on ancient toolchains. It's probably also a safe assumption that anyone with an older libc version won't be using the latest kernel headers, so I think we can still do this across architectures if both glibc and musl already require a compiler that is new enough, or alternatively if we know that the kernel headers require a new compiler for other reasons and nobody has complained. For glibc, it looks the minimum compiler version was raised from gcc-5 to gcc-8 four years ago, so we should be fine. In musl, the documentation states that at least gcc-3.4 or clang-3.2 are required, which probably predate the __SIZEOF_LONG__ macro. On the other hand, musl was only released in 2011, and building musl itself explicitly does not require kernel uapi headers, so this may not be too critical. There is also uClibc, but I could not find any minimum supported compiler version for that. Most commonly, this one is used for cross-build environments, so it's also less likely to have libc/gcc/headers being wildly out of sync. Not sure. Arnd [1] https://sourceware.org/pipermail/libc-alpha/2019-January/101010.html Thanks Arnd for the detailed reply. Any more comments? What should I do in the next step? I think the summary is "it's probably fine", but I don't know for sure, and it may not be worth the benefit. Thank you, it is very clear now. Maybe you can prepare a v2 that only does this for the newer architectures I mentioned above, with and an explanation and link to my above reply in the file comments? Only arm64, riscv and loongarch belong to the newer architectures which are related with this change, I am not sure it is necessary to "unify" uapi bitsperlong.h for them. Anyway, let me try, I will send a new version, maybe this is going to progress in the right direction. Thanks, Tiezhu
Re: [RFC PATCH] asm-generic: Unify uapi bitsperlong.h
On Thu, Jun 8, 2023, at 09:04, Tiezhu Yang wrote: > On 05/09/2023 05:37 PM, Arnd Bergmann wrote: >> On Tue, May 9, 2023, at 09:05, Tiezhu Yang wrote: >> >> I think we are completely safe on the architectures that were >> added since the linux-3.x days (arm64, riscv, csky, openrisc, >> loongarch, nios2, and hexagon), but for the older ones there >> is a regression risk. Especially on targets that are not that >> actively maintained (sparc, alpha, ia64, sh, ...) there is >> a good chance that users are stuck on ancient toolchains. >> It's probably also a safe assumption that anyone with an older >> libc version won't be using the latest kernel headers, so >> I think we can still do this across architectures if both >> glibc and musl already require a compiler that is new enough, >> or alternatively if we know that the kernel headers require >> a new compiler for other reasons and nobody has complained. >> >> For glibc, it looks the minimum compiler version was raised >> from gcc-5 to gcc-8 four years ago, so we should be fine. >> >> In musl, the documentation states that at least gcc-3.4 or >> clang-3.2 are required, which probably predate the >> __SIZEOF_LONG__ macro. On the other hand, musl was only >> released in 2011, and building musl itself explicitly >> does not require kernel uapi headers, so this may not >> be too critical. >> >> There is also uClibc, but I could not find any minimum >> supported compiler version for that. Most commonly, this >> one is used for cross-build environments, so it's also >> less likely to have libc/gcc/headers being wildly out of >> sync. Not sure. >> >> Arnd >> >> [1] https://sourceware.org/pipermail/libc-alpha/2019-January/101010.html >> > > Thanks Arnd for the detailed reply. > Any more comments? What should I do in the next step? I think the summary is "it's probably fine", but I don't know for sure, and it may not be worth the benefit. Maybe you can prepare a v2 that only does this for the newer architectures I mentioned above, with and an explanation and link to my above reply in the file comments? Arnd
Re: [RFC PATCH] asm-generic: Unify uapi bitsperlong.h
Hi all, On 05/09/2023 05:37 PM, Arnd Bergmann wrote: On Tue, May 9, 2023, at 09:05, Tiezhu Yang wrote: Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0 in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are usable, just define __BITS_PER_LONG as (__CHAR_BIT__ * __SIZEOF_LONG__) in asm-generic uapi bitsperlong.h, simpler, works everywhere. Remove all the arch specific uapi bitsperlong.h which will be generated as arch/*/include/generated/uapi/asm/bitsperlong.h. Suggested-by: Xi Ruoyao Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.ca...@xry111.site/ Signed-off-by: Tiezhu Yang I originally introduced the bitsperlong.h header, and I'd love to see it removed if it's no longer needed. Your patch certainly seems like it does this well. There is one minor obstacle to this, which is that the compiler requirements for uapi headers are not the same as for kernel internal code. In particular, the uapi headers may be included by user space code that is built with an older compiler version, or with a compiler that is not gcc or clang. I think we are completely safe on the architectures that were added since the linux-3.x days (arm64, riscv, csky, openrisc, loongarch, nios2, and hexagon), but for the older ones there is a regression risk. Especially on targets that are not that actively maintained (sparc, alpha, ia64, sh, ...) there is a good chance that users are stuck on ancient toolchains. It's probably also a safe assumption that anyone with an older libc version won't be using the latest kernel headers, so I think we can still do this across architectures if both glibc and musl already require a compiler that is new enough, or alternatively if we know that the kernel headers require a new compiler for other reasons and nobody has complained. For glibc, it looks the minimum compiler version was raised from gcc-5 to gcc-8 four years ago, so we should be fine. In musl, the documentation states that at least gcc-3.4 or clang-3.2 are required, which probably predate the __SIZEOF_LONG__ macro. On the other hand, musl was only released in 2011, and building musl itself explicitly does not require kernel uapi headers, so this may not be too critical. There is also uClibc, but I could not find any minimum supported compiler version for that. Most commonly, this one is used for cross-build environments, so it's also less likely to have libc/gcc/headers being wildly out of sync. Not sure. Arnd [1] https://sourceware.org/pipermail/libc-alpha/2019-January/101010.html Thanks Arnd for the detailed reply. Any more comments? What should I do in the next step? Thanks, Tiezhu
Re: [RFC PATCH] asm-generic: Unify uapi bitsperlong.h
On Tue, May 9, 2023, at 09:05, Tiezhu Yang wrote: > Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0 > in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are > usable, just define __BITS_PER_LONG as (__CHAR_BIT__ * __SIZEOF_LONG__) in > asm-generic uapi bitsperlong.h, simpler, works everywhere. > > Remove all the arch specific uapi bitsperlong.h which will be generated as > arch/*/include/generated/uapi/asm/bitsperlong.h. > > Suggested-by: Xi Ruoyao > Link: > https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.ca...@xry111.site/ > Signed-off-by: Tiezhu Yang I originally introduced the bitsperlong.h header, and I'd love to see it removed if it's no longer needed. Your patch certainly seems like it does this well. There is one minor obstacle to this, which is that the compiler requirements for uapi headers are not the same as for kernel internal code. In particular, the uapi headers may be included by user space code that is built with an older compiler version, or with a compiler that is not gcc or clang. I think we are completely safe on the architectures that were added since the linux-3.x days (arm64, riscv, csky, openrisc, loongarch, nios2, and hexagon), but for the older ones there is a regression risk. Especially on targets that are not that actively maintained (sparc, alpha, ia64, sh, ...) there is a good chance that users are stuck on ancient toolchains. It's probably also a safe assumption that anyone with an older libc version won't be using the latest kernel headers, so I think we can still do this across architectures if both glibc and musl already require a compiler that is new enough, or alternatively if we know that the kernel headers require a new compiler for other reasons and nobody has complained. For glibc, it looks the minimum compiler version was raised from gcc-5 to gcc-8 four years ago, so we should be fine. In musl, the documentation states that at least gcc-3.4 or clang-3.2 are required, which probably predate the __SIZEOF_LONG__ macro. On the other hand, musl was only released in 2011, and building musl itself explicitly does not require kernel uapi headers, so this may not be too critical. There is also uClibc, but I could not find any minimum supported compiler version for that. Most commonly, this one is used for cross-build environments, so it's also less likely to have libc/gcc/headers being wildly out of sync. Not sure. Arnd [1] https://sourceware.org/pipermail/libc-alpha/2019-January/101010.html
[RFC PATCH] asm-generic: Unify uapi bitsperlong.h
Now we specify the minimal version of GCC as 5.1 and Clang/LLVM as 11.0.0 in Documentation/process/changes.rst, __CHAR_BIT__ and __SIZEOF_LONG__ are usable, just define __BITS_PER_LONG as (__CHAR_BIT__ * __SIZEOF_LONG__) in asm-generic uapi bitsperlong.h, simpler, works everywhere. Remove all the arch specific uapi bitsperlong.h which will be generated as arch/*/include/generated/uapi/asm/bitsperlong.h. Suggested-by: Xi Ruoyao Link: https://lore.kernel.org/all/d3e255e4746de44c9903c4433616d44ffcf18d1b.ca...@xry111.site/ Signed-off-by: Tiezhu Yang --- This is based on 6.4-rc1 arch/alpha/include/uapi/asm/bitsperlong.h | 9 arch/arm64/include/uapi/asm/bitsperlong.h | 24 --- arch/ia64/include/uapi/asm/bitsperlong.h | 9 arch/loongarch/include/uapi/asm/bitsperlong.h | 9 arch/mips/include/uapi/asm/bitsperlong.h | 9 arch/parisc/include/uapi/asm/bitsperlong.h | 13 --- arch/powerpc/include/uapi/asm/bitsperlong.h| 13 --- arch/riscv/include/uapi/asm/bitsperlong.h | 14 --- arch/s390/include/uapi/asm/bitsperlong.h | 14 --- arch/sparc/include/uapi/asm/bitsperlong.h | 14 --- arch/x86/include/uapi/asm/bitsperlong.h| 14 --- include/uapi/asm-generic/bitsperlong.h | 11 + tools/arch/alpha/include/uapi/asm/bitsperlong.h| 9 tools/arch/arm64/include/uapi/asm/bitsperlong.h| 24 --- tools/arch/hexagon/include/uapi/asm/bitsperlong.h | 27 -- tools/arch/ia64/include/uapi/asm/bitsperlong.h | 9 .../arch/loongarch/include/uapi/asm/bitsperlong.h | 9 .../arch/microblaze/include/uapi/asm/bitsperlong.h | 2 -- tools/arch/mips/include/uapi/asm/bitsperlong.h | 9 tools/arch/parisc/include/uapi/asm/bitsperlong.h | 15 tools/arch/powerpc/include/uapi/asm/bitsperlong.h | 13 --- tools/arch/riscv/include/uapi/asm/bitsperlong.h| 14 --- tools/arch/s390/include/uapi/asm/bitsperlong.h | 13 --- tools/arch/sparc/include/uapi/asm/bitsperlong.h| 13 --- tools/arch/x86/include/uapi/asm/bitsperlong.h | 13 --- tools/include/uapi/asm-generic/bitsperlong.h | 12 ++ tools/include/uapi/asm/bitsperlong.h | 24 --- 27 files changed, 3 insertions(+), 356 deletions(-) delete mode 100644 arch/alpha/include/uapi/asm/bitsperlong.h delete mode 100644 arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/ia64/include/uapi/asm/bitsperlong.h delete mode 100644 arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 arch/mips/include/uapi/asm/bitsperlong.h delete mode 100644 arch/parisc/include/uapi/asm/bitsperlong.h delete mode 100644 arch/powerpc/include/uapi/asm/bitsperlong.h delete mode 100644 arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 arch/s390/include/uapi/asm/bitsperlong.h delete mode 100644 arch/sparc/include/uapi/asm/bitsperlong.h delete mode 100644 arch/x86/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/alpha/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/arm64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/hexagon/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/ia64/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/loongarch/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/microblaze/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/mips/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/parisc/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/powerpc/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/riscv/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/s390/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/sparc/include/uapi/asm/bitsperlong.h delete mode 100644 tools/arch/x86/include/uapi/asm/bitsperlong.h delete mode 100644 tools/include/uapi/asm/bitsperlong.h diff --git a/arch/alpha/include/uapi/asm/bitsperlong.h b/arch/alpha/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 6c5bf7d..000 --- a/arch/alpha/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,9 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef __ASM_ALPHA_BITSPERLONG_H -#define __ASM_ALPHA_BITSPERLONG_H - -#define __BITS_PER_LONG 64 - -#include - -#endif /* __ASM_ALPHA_BITSPERLONG_H */ diff --git a/arch/arm64/include/uapi/asm/bitsperlong.h b/arch/arm64/include/uapi/asm/bitsperlong.h deleted file mode 100644 index 485d60be..000 --- a/arch/arm64/include/uapi/asm/bitsperlong.h +++ /dev/null @@ -1,24 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -/* - * Copyright (C) 2012 ARM Ltd. - * - * This program is free software; you can redistribute it and/or modify - * it
