| Message ID | 20230302093539.372962-1-alexghiti@rivosinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Remove COMMAND_LINE_SIZE from uapi | expand |
Hi Alex, On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > This all came up in the context of increasing COMMAND_LINE_SIZE in the > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > maximum length of /proc/cmdline and userspace could staticly rely on > that to be correct. > > Usually I wouldn't mess around with changing this sort of thing, but > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > increasing, but they're from before the UAPI split so I'm not quite sure > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > asm-generic/setup.h."). > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > part of the uapi to begin with, and userspace should be able to handle > /proc/cmdline of whatever length it turns out to be. I don't see any > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > search, but that's not really enough to consider it unused on my end. > > This issue was already considered in s390 and they reached the same > conclusion in commit 622021cd6c56 ("s390: make command line > configurable"). > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > shouldn't be part of uapi, so this now touches all the ports. I've > tried to split this all out and leave it bisectable, but I haven't > tested it all that aggressively. > > Changes since v3 <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: > * Added RB/AB > * Added a mention to commit 622021cd6c56 ("s390: make command line > configurable") in the cover letter Thanks for the update! Apparently you forgot to add your own SoB? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Arnd, On 3/2/23 10:35, Alexandre Ghiti wrote: > This all came up in the context of increasing COMMAND_LINE_SIZE in the > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > maximum length of /proc/cmdline and userspace could staticly rely on > that to be correct. > > Usually I wouldn't mess around with changing this sort of thing, but > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > increasing, but they're from before the UAPI split so I'm not quite sure > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > asm-generic/setup.h."). > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > part of the uapi to begin with, and userspace should be able to handle > /proc/cmdline of whatever length it turns out to be. I don't see any > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > search, but that's not really enough to consider it unused on my end. > > This issue was already considered in s390 and they reached the same > conclusion in commit 622021cd6c56 ("s390: make command line > configurable"). > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > shouldn't be part of uapi, so this now touches all the ports. I've > tried to split this all out and leave it bisectable, but I haven't > tested it all that aggressively. > > Changes since v3 <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: > * Added RB/AB > * Added a mention to commit 622021cd6c56 ("s390: make command line > configurable") in the cover letter > > Changes since v2 <https://lore.kernel.org/all/20221211061358.28035-1-palmer@rivosinc.com/>: > * Fix sh, csky and ia64 builds, as reported by kernel test robot > > Changes since v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: > * Touches every arch. > > base-commit-tag: next-20230207 > > Palmer Dabbelt (24): > alpha: Remove COMMAND_LINE_SIZE from uapi > arm64: Remove COMMAND_LINE_SIZE from uapi > arm: Remove COMMAND_LINE_SIZE from uapi > ia64: Remove COMMAND_LINE_SIZE from uapi > m68k: Remove COMMAND_LINE_SIZE from uapi > microblaze: Remove COMMAND_LINE_SIZE from uapi > mips: Remove COMMAND_LINE_SIZE from uapi > parisc: Remove COMMAND_LINE_SIZE from uapi > powerpc: Remove COMMAND_LINE_SIZE from uapi > sparc: Remove COMMAND_LINE_SIZE from uapi > xtensa: Remove COMMAND_LINE_SIZE from uapi > asm-generic: Remove COMMAND_LINE_SIZE from uapi > alpha: Remove empty <uapi/asm/setup.h> > arc: Remove empty <uapi/asm/setup.h> > m68k: Remove empty <uapi/asm/setup.h> > arm64: Remove empty <uapi/asm/setup.h> > microblaze: Remove empty <uapi/asm/setup.h> > sparc: Remove empty <uapi/asm/setup.h> > parisc: Remove empty <uapi/asm/setup.h> > x86: Remove empty <uapi/asm/setup.h> > xtensa: Remove empty <uapi/asm/setup.h> > powerpc: Remove empty <uapi/asm/setup.h> > mips: Remove empty <uapi/asm/setup.h> > s390: Remove empty <uapi/asm/setup.h> > > .../admin-guide/kernel-parameters.rst | 2 +- > arch/alpha/include/asm/setup.h | 4 +-- > arch/alpha/include/uapi/asm/setup.h | 7 ----- > arch/arc/include/asm/setup.h | 1 - > arch/arc/include/uapi/asm/setup.h | 6 ----- > arch/arm/include/asm/setup.h | 1 + > arch/arm/include/uapi/asm/setup.h | 2 -- > arch/arm64/include/asm/setup.h | 3 ++- > arch/arm64/include/uapi/asm/setup.h | 27 ------------------- > arch/ia64/include/asm/setup.h | 10 +++++++ > arch/ia64/include/uapi/asm/setup.h | 6 ++--- > arch/loongarch/include/asm/setup.h | 2 +- > arch/m68k/include/asm/setup.h | 3 +-- > arch/m68k/include/uapi/asm/setup.h | 17 ------------ > arch/microblaze/include/asm/setup.h | 2 +- > arch/microblaze/include/uapi/asm/setup.h | 20 -------------- > arch/mips/include/asm/setup.h | 3 ++- > arch/mips/include/uapi/asm/setup.h | 8 ------ > arch/parisc/include/{uapi => }/asm/setup.h | 0 > arch/powerpc/include/asm/setup.h | 2 +- > arch/powerpc/include/uapi/asm/setup.h | 7 ----- > arch/s390/include/asm/setup.h | 1 - > arch/s390/include/uapi/asm/setup.h | 1 - > arch/sh/include/asm/setup.h | 2 +- > arch/sparc/include/asm/setup.h | 6 ++++- > arch/sparc/include/uapi/asm/setup.h | 16 ----------- > arch/x86/include/asm/setup.h | 2 -- > arch/x86/include/uapi/asm/setup.h | 1 - > arch/xtensa/include/{uapi => }/asm/setup.h | 0 > include/asm-generic/Kbuild | 1 + > include/{uapi => }/asm-generic/setup.h | 0 > include/uapi/asm-generic/Kbuild | 1 - > 32 files changed, 31 insertions(+), 133 deletions(-) > delete mode 100644 arch/alpha/include/uapi/asm/setup.h > delete mode 100644 arch/arc/include/uapi/asm/setup.h > delete mode 100644 arch/arm64/include/uapi/asm/setup.h > create mode 100644 arch/ia64/include/asm/setup.h > delete mode 100644 arch/m68k/include/uapi/asm/setup.h > delete mode 100644 arch/microblaze/include/uapi/asm/setup.h > delete mode 100644 arch/mips/include/uapi/asm/setup.h > rename arch/parisc/include/{uapi => }/asm/setup.h (100%) > delete mode 100644 arch/powerpc/include/uapi/asm/setup.h > delete mode 100644 arch/s390/include/uapi/asm/setup.h > delete mode 100644 arch/sparc/include/uapi/asm/setup.h > delete mode 100644 arch/x86/include/uapi/asm/setup.h > rename arch/xtensa/include/{uapi => }/asm/setup.h (100%) > rename include/{uapi => }/asm-generic/setup.h (100%) > Björn noticed that I should also remove the command line size for riscv since it was picked up in 6.3 by Palmer...I send a v6 right now, sorry about that. Alex
Hi Geert, On 3/2/23 10:47, Geert Uytterhoeven wrote: > Hi Alex, > > On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: >> This all came up in the context of increasing COMMAND_LINE_SIZE in the >> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the >> maximum length of /proc/cmdline and userspace could staticly rely on >> that to be correct. >> >> Usually I wouldn't mess around with changing this sort of thing, but >> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE >> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE >> increasing, but they're from before the UAPI split so I'm not quite sure >> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from >> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel >> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), >> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from >> asm-generic/setup.h."). >> >> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been >> part of the uapi to begin with, and userspace should be able to handle >> /proc/cmdline of whatever length it turns out to be. I don't see any >> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google >> search, but that's not really enough to consider it unused on my end. >> >> This issue was already considered in s390 and they reached the same >> conclusion in commit 622021cd6c56 ("s390: make command line >> configurable"). >> >> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really >> shouldn't be part of uapi, so this now touches all the ports. I've >> tried to split this all out and leave it bisectable, but I haven't >> tested it all that aggressively. >> >> Changes since v3 <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: >> * Added RB/AB >> * Added a mention to commit 622021cd6c56 ("s390: make command line >> configurable") in the cover letter > Thanks for the update! > > Apparently you forgot to add your own SoB? I do not know, should I? Palmer did all the work, I only fixed 3 minor things > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Alex, On Thu, Mar 2, 2023 at 11:09 AM Alexandre Ghiti <alex@ghiti.fr> wrote: > On 3/2/23 10:47, Geert Uytterhoeven wrote: > > On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > >> This all came up in the context of increasing COMMAND_LINE_SIZE in the > >> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > >> maximum length of /proc/cmdline and userspace could staticly rely on > >> that to be correct. > >> > >> Usually I wouldn't mess around with changing this sort of thing, but > >> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > >> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > >> increasing, but they're from before the UAPI split so I'm not quite sure > >> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > >> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > >> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > >> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > >> asm-generic/setup.h."). > >> > >> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > >> part of the uapi to begin with, and userspace should be able to handle > >> /proc/cmdline of whatever length it turns out to be. I don't see any > >> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > >> search, but that's not really enough to consider it unused on my end. > >> > >> This issue was already considered in s390 and they reached the same > >> conclusion in commit 622021cd6c56 ("s390: make command line > >> configurable"). > >> > >> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > >> shouldn't be part of uapi, so this now touches all the ports. I've > >> tried to split this all out and leave it bisectable, but I haven't > >> tested it all that aggressively. > >> > >> Changes since v3 <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: > >> * Added RB/AB > >> * Added a mention to commit 622021cd6c56 ("s390: make command line > >> configurable") in the cover letter > > Thanks for the update! > > > > Apparently you forgot to add your own SoB? > > I do not know, should I? Palmer did all the work, I only fixed 3 minor > things If you are picking up patches, and submitting them to someone else for upstream inclusion, you should add your own SoB. https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst#L419 Gr{oetje,eeting}s, Geert
On 3/2/23 11:44, Geert Uytterhoeven wrote: > Hi Alex, > > On Thu, Mar 2, 2023 at 11:09 AM Alexandre Ghiti <alex@ghiti.fr> wrote: >> On 3/2/23 10:47, Geert Uytterhoeven wrote: >>> On Thu, Mar 2, 2023 at 10:35 AM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: >>>> This all came up in the context of increasing COMMAND_LINE_SIZE in the >>>> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the >>>> maximum length of /proc/cmdline and userspace could staticly rely on >>>> that to be correct. >>>> >>>> Usually I wouldn't mess around with changing this sort of thing, but >>>> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE >>>> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE >>>> increasing, but they're from before the UAPI split so I'm not quite sure >>>> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from >>>> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel >>>> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), >>>> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from >>>> asm-generic/setup.h."). >>>> >>>> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been >>>> part of the uapi to begin with, and userspace should be able to handle >>>> /proc/cmdline of whatever length it turns out to be. I don't see any >>>> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google >>>> search, but that's not really enough to consider it unused on my end. >>>> >>>> This issue was already considered in s390 and they reached the same >>>> conclusion in commit 622021cd6c56 ("s390: make command line >>>> configurable"). >>>> >>>> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really >>>> shouldn't be part of uapi, so this now touches all the ports. I've >>>> tried to split this all out and leave it bisectable, but I haven't >>>> tested it all that aggressively. >>>> >>>> Changes since v3 <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: >>>> * Added RB/AB >>>> * Added a mention to commit 622021cd6c56 ("s390: make command line >>>> configurable") in the cover letter >>> Thanks for the update! >>> >>> Apparently you forgot to add your own SoB? >> I do not know, should I? Palmer did all the work, I only fixed 3 minor >> things > If you are picking up patches, and submitting them to someone else > for upstream inclusion, you should add your own SoB. > https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst#L419 Great, thanks for the pointer, I'll do that then! Thanks again, Alex > Gr{oetje,eeting}s, > > Geert >
On 3/2/23 11:06, Alexandre Ghiti wrote: > Hi Arnd, > > On 3/2/23 10:35, Alexandre Ghiti wrote: >> This all came up in the context of increasing COMMAND_LINE_SIZE in the >> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the >> maximum length of /proc/cmdline and userspace could staticly rely on >> that to be correct. >> >> Usually I wouldn't mess around with changing this sort of thing, but >> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE >> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE >> increasing, but they're from before the UAPI split so I'm not quite sure >> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from >> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel >> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), >> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from >> asm-generic/setup.h."). >> >> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been >> part of the uapi to begin with, and userspace should be able to handle >> /proc/cmdline of whatever length it turns out to be. I don't see any >> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google >> search, but that's not really enough to consider it unused on my end. >> >> This issue was already considered in s390 and they reached the same >> conclusion in commit 622021cd6c56 ("s390: make command line >> configurable"). >> >> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really >> shouldn't be part of uapi, so this now touches all the ports. I've >> tried to split this all out and leave it bisectable, but I haven't >> tested it all that aggressively. >> >> Changes since v3 >> <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: >> * Added RB/AB >> * Added a mention to commit 622021cd6c56 ("s390: make command line >> configurable") in the cover letter >> >> Changes since v2 >> <https://lore.kernel.org/all/20221211061358.28035-1-palmer@rivosinc.com/>: >> * Fix sh, csky and ia64 builds, as reported by kernel test robot >> >> Changes since v1 >> <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: >> * Touches every arch. >> >> base-commit-tag: next-20230207 >> >> Palmer Dabbelt (24): >> alpha: Remove COMMAND_LINE_SIZE from uapi >> arm64: Remove COMMAND_LINE_SIZE from uapi >> arm: Remove COMMAND_LINE_SIZE from uapi >> ia64: Remove COMMAND_LINE_SIZE from uapi >> m68k: Remove COMMAND_LINE_SIZE from uapi >> microblaze: Remove COMMAND_LINE_SIZE from uapi >> mips: Remove COMMAND_LINE_SIZE from uapi >> parisc: Remove COMMAND_LINE_SIZE from uapi >> powerpc: Remove COMMAND_LINE_SIZE from uapi >> sparc: Remove COMMAND_LINE_SIZE from uapi >> xtensa: Remove COMMAND_LINE_SIZE from uapi >> asm-generic: Remove COMMAND_LINE_SIZE from uapi >> alpha: Remove empty <uapi/asm/setup.h> >> arc: Remove empty <uapi/asm/setup.h> >> m68k: Remove empty <uapi/asm/setup.h> >> arm64: Remove empty <uapi/asm/setup.h> >> microblaze: Remove empty <uapi/asm/setup.h> >> sparc: Remove empty <uapi/asm/setup.h> >> parisc: Remove empty <uapi/asm/setup.h> >> x86: Remove empty <uapi/asm/setup.h> >> xtensa: Remove empty <uapi/asm/setup.h> >> powerpc: Remove empty <uapi/asm/setup.h> >> mips: Remove empty <uapi/asm/setup.h> >> s390: Remove empty <uapi/asm/setup.h> >> >> .../admin-guide/kernel-parameters.rst | 2 +- >> arch/alpha/include/asm/setup.h | 4 +-- >> arch/alpha/include/uapi/asm/setup.h | 7 ----- >> arch/arc/include/asm/setup.h | 1 - >> arch/arc/include/uapi/asm/setup.h | 6 ----- >> arch/arm/include/asm/setup.h | 1 + >> arch/arm/include/uapi/asm/setup.h | 2 -- >> arch/arm64/include/asm/setup.h | 3 ++- >> arch/arm64/include/uapi/asm/setup.h | 27 ------------------- >> arch/ia64/include/asm/setup.h | 10 +++++++ >> arch/ia64/include/uapi/asm/setup.h | 6 ++--- >> arch/loongarch/include/asm/setup.h | 2 +- >> arch/m68k/include/asm/setup.h | 3 +-- >> arch/m68k/include/uapi/asm/setup.h | 17 ------------ >> arch/microblaze/include/asm/setup.h | 2 +- >> arch/microblaze/include/uapi/asm/setup.h | 20 -------------- >> arch/mips/include/asm/setup.h | 3 ++- >> arch/mips/include/uapi/asm/setup.h | 8 ------ >> arch/parisc/include/{uapi => }/asm/setup.h | 0 >> arch/powerpc/include/asm/setup.h | 2 +- >> arch/powerpc/include/uapi/asm/setup.h | 7 ----- >> arch/s390/include/asm/setup.h | 1 - >> arch/s390/include/uapi/asm/setup.h | 1 - >> arch/sh/include/asm/setup.h | 2 +- >> arch/sparc/include/asm/setup.h | 6 ++++- >> arch/sparc/include/uapi/asm/setup.h | 16 ----------- >> arch/x86/include/asm/setup.h | 2 -- >> arch/x86/include/uapi/asm/setup.h | 1 - >> arch/xtensa/include/{uapi => }/asm/setup.h | 0 >> include/asm-generic/Kbuild | 1 + >> include/{uapi => }/asm-generic/setup.h | 0 >> include/uapi/asm-generic/Kbuild | 1 - >> 32 files changed, 31 insertions(+), 133 deletions(-) >> delete mode 100644 arch/alpha/include/uapi/asm/setup.h >> delete mode 100644 arch/arc/include/uapi/asm/setup.h >> delete mode 100644 arch/arm64/include/uapi/asm/setup.h >> create mode 100644 arch/ia64/include/asm/setup.h >> delete mode 100644 arch/m68k/include/uapi/asm/setup.h >> delete mode 100644 arch/microblaze/include/uapi/asm/setup.h >> delete mode 100644 arch/mips/include/uapi/asm/setup.h >> rename arch/parisc/include/{uapi => }/asm/setup.h (100%) >> delete mode 100644 arch/powerpc/include/uapi/asm/setup.h >> delete mode 100644 arch/s390/include/uapi/asm/setup.h >> delete mode 100644 arch/sparc/include/uapi/asm/setup.h >> delete mode 100644 arch/x86/include/uapi/asm/setup.h >> rename arch/xtensa/include/{uapi => }/asm/setup.h (100%) >> rename include/{uapi => }/asm-generic/setup.h (100%) >> > Björn noticed that I should also remove the command line size for > riscv since it was picked up in 6.3 by Palmer...I send a v6 right now, > sorry about that. > > Alex > Hmmm when implementing the riscv patch, I noticed that the patches that introduce a new include/asm/setup.h file add the following SPDX header: /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ To me we should not add "WITH Linux-syscall-note" as this header is not part of the user visible headers: any opinion before I send the v5? Thanks, Alex
This all came up in the context of increasing COMMAND_LINE_SIZE in the RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the maximum length of /proc/cmdline and userspace could staticly rely on that to be correct. Usually I wouldn't mess around with changing this sort of thing, but PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE increasing, but they're from before the UAPI split so I'm not quite sure what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from asm-generic/setup.h."). It seems to me like COMMAND_LINE_SIZE really just shouldn't have been part of the uapi to begin with, and userspace should be able to handle /proc/cmdline of whatever length it turns out to be. I don't see any references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google search, but that's not really enough to consider it unused on my end. This issue was already considered in s390 and they reached the same conclusion in commit 622021cd6c56 ("s390: make command line configurable"). The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really shouldn't be part of uapi, so this now touches all the ports. I've tried to split this all out and leave it bisectable, but I haven't tested it all that aggressively. Changes since v3 <https://lore.kernel.org/all/20230214074925.228106-1-alexghiti@rivosinc.com/>: * Added RB/AB * Added a mention to commit 622021cd6c56 ("s390: make command line configurable") in the cover letter Changes since v2 <https://lore.kernel.org/all/20221211061358.28035-1-palmer@rivosinc.com/>: * Fix sh, csky and ia64 builds, as reported by kernel test robot Changes since v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: * Touches every arch. base-commit-tag: next-20230207 Palmer Dabbelt (24): alpha: Remove COMMAND_LINE_SIZE from uapi arm64: Remove COMMAND_LINE_SIZE from uapi arm: Remove COMMAND_LINE_SIZE from uapi ia64: Remove COMMAND_LINE_SIZE from uapi m68k: Remove COMMAND_LINE_SIZE from uapi microblaze: Remove COMMAND_LINE_SIZE from uapi mips: Remove COMMAND_LINE_SIZE from uapi parisc: Remove COMMAND_LINE_SIZE from uapi powerpc: Remove COMMAND_LINE_SIZE from uapi sparc: Remove COMMAND_LINE_SIZE from uapi xtensa: Remove COMMAND_LINE_SIZE from uapi asm-generic: Remove COMMAND_LINE_SIZE from uapi alpha: Remove empty <uapi/asm/setup.h> arc: Remove empty <uapi/asm/setup.h> m68k: Remove empty <uapi/asm/setup.h> arm64: Remove empty <uapi/asm/setup.h> microblaze: Remove empty <uapi/asm/setup.h> sparc: Remove empty <uapi/asm/setup.h> parisc: Remove empty <uapi/asm/setup.h> x86: Remove empty <uapi/asm/setup.h> xtensa: Remove empty <uapi/asm/setup.h> powerpc: Remove empty <uapi/asm/setup.h> mips: Remove empty <uapi/asm/setup.h> s390: Remove empty <uapi/asm/setup.h> .../admin-guide/kernel-parameters.rst | 2 +- arch/alpha/include/asm/setup.h | 4 +-- arch/alpha/include/uapi/asm/setup.h | 7 ----- arch/arc/include/asm/setup.h | 1 - arch/arc/include/uapi/asm/setup.h | 6 ----- arch/arm/include/asm/setup.h | 1 + arch/arm/include/uapi/asm/setup.h | 2 -- arch/arm64/include/asm/setup.h | 3 ++- arch/arm64/include/uapi/asm/setup.h | 27 ------------------- arch/ia64/include/asm/setup.h | 10 +++++++ arch/ia64/include/uapi/asm/setup.h | 6 ++--- arch/loongarch/include/asm/setup.h | 2 +- arch/m68k/include/asm/setup.h | 3 +-- arch/m68k/include/uapi/asm/setup.h | 17 ------------ arch/microblaze/include/asm/setup.h | 2 +- arch/microblaze/include/uapi/asm/setup.h | 20 -------------- arch/mips/include/asm/setup.h | 3 ++- arch/mips/include/uapi/asm/setup.h | 8 ------ arch/parisc/include/{uapi => }/asm/setup.h | 0 arch/powerpc/include/asm/setup.h | 2 +- arch/powerpc/include/uapi/asm/setup.h | 7 ----- arch/s390/include/asm/setup.h | 1 - arch/s390/include/uapi/asm/setup.h | 1 - arch/sh/include/asm/setup.h | 2 +- arch/sparc/include/asm/setup.h | 6 ++++- arch/sparc/include/uapi/asm/setup.h | 16 ----------- arch/x86/include/asm/setup.h | 2 -- arch/x86/include/uapi/asm/setup.h | 1 - arch/xtensa/include/{uapi => }/asm/setup.h | 0 include/asm-generic/Kbuild | 1 + include/{uapi => }/asm-generic/setup.h | 0 include/uapi/asm-generic/Kbuild | 1 - 32 files changed, 31 insertions(+), 133 deletions(-) delete mode 100644 arch/alpha/include/uapi/asm/setup.h delete mode 100644 arch/arc/include/uapi/asm/setup.h delete mode 100644 arch/arm64/include/uapi/asm/setup.h create mode 100644 arch/ia64/include/asm/setup.h delete mode 100644 arch/m68k/include/uapi/asm/setup.h delete mode 100644 arch/microblaze/include/uapi/asm/setup.h delete mode 100644 arch/mips/include/uapi/asm/setup.h rename arch/parisc/include/{uapi => }/asm/setup.h (100%) delete mode 100644 arch/powerpc/include/uapi/asm/setup.h delete mode 100644 arch/s390/include/uapi/asm/setup.h delete mode 100644 arch/sparc/include/uapi/asm/setup.h delete mode 100644 arch/x86/include/uapi/asm/setup.h rename arch/xtensa/include/{uapi => }/asm/setup.h (100%) rename include/{uapi => }/asm-generic/setup.h (100%)