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.
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 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%)
--
2.37.2
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/alpha/include/asm/setup.h | 4 ++--
arch/alpha/include/uapi/asm/setup.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/arm64/include/asm/setup.h | 3 ++-
arch/arm64/include/uapi/asm/setup.h | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/arm/include/asm/setup.h | 1 +
arch/arm/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/ia64/include/asm/setup.h | 10 ++++++++++
arch/ia64/include/uapi/asm/setup.h | 6 ++----
2 files changed, 12 insertions(+), 4 deletions(-)
create mode 100644 arch/ia64/include/asm/setup.h
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/m68k/include/asm/setup.h | 3 +--
arch/m68k/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/microblaze/include/asm/setup.h | 2 +-
arch/microblaze/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/mips/include/asm/setup.h | 3 ++-
arch/mips/include/uapi/asm/setup.h | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/parisc/include/asm/setup.h | 7 +++++++
arch/parisc/include/uapi/asm/setup.h | 2 --
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 arch/parisc/include/asm/setup.h
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/sparc/include/asm/setup.h | 6 +++++-
arch/sparc/include/uapi/asm/setup.h | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/xtensa/include/asm/setup.h | 17 +++++++++++++++++
arch/xtensa/include/uapi/asm/setup.h | 2 --
2 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 arch/xtensa/include/asm/setup.h
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API. Since <uapi/asm-generic/setup.h> only
contains COMMAND_LINE_SIZE we can just move it out of uapi to hide the
definition and fix up the only direct use in Loongarch.
Signed-off-by: Palmer Dabbelt <redacted>
Link: https://lore.kernel.org/r/20210423025545.313965-1-palmer@dabbelt.com
Signed-off-by: Palmer Dabbelt <redacted>
---
Documentation/admin-guide/kernel-parameters.rst | 2 +-
arch/loongarch/include/asm/setup.h | 2 +-
arch/sh/include/asm/setup.h | 2 +-
include/asm-generic/Kbuild | 1 +
include/{uapi => }/asm-generic/setup.h | 0
include/uapi/asm-generic/Kbuild | 1 -
6 files changed, 4 insertions(+), 4 deletions(-)
rename include/{uapi => }/asm-generic/setup.h (100%)
@@ -207,7 +207,7 @@ The number of kernel parameters is not limited, but the length of the complete command line (parameters including spaces etc.) is limited to a fixed number of characters. This limit depends on the architecture and is between 256 and 4096 characters. It is defined in the file-./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.+./include/asm-generic/setup.h as COMMAND_LINE_SIZE. Finally, the [KMG] suffix is commonly described after a number of kernel parameter values. These 'K', 'M', and 'G' letters represent the _binary_
@@ -1,6 +0,0 @@-/*- * setup.h is part of userspace header ABI so UAPI scripts have to generate it- * even if there's nothing to export - causing empty <uapi/asm/setup.h>- * However to prevent "patch" from discarding it we add this placeholder- * comment- */
@@ -1,15 +0,0 @@-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */-/*-** asm/setup.h -- Definition of the Linux/m68k setup information-**-** Copyright 1992 by Greg Harp-**-** This file is subject to the terms and conditions of the GNU General Public-** License. See the file COPYING in the main directory of this archive-** for more details.-*/--#ifndef _UAPI_M68K_SETUP_H-#define _UAPI_M68K_SETUP_H--#endif /* _UAPI_M68K_SETUP_H */
@@ -1,25 +0,0 @@-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */-/*- * Based on arch/arm/include/asm/setup.h- *- * Copyright (C) 1997-1999 Russell King- * Copyright (C) 2012 ARM Ltd.- *- * This program is free software; you can redistribute it and/or modify- * it under the terms of the GNU General Public License version 2 as- * published by the Free Software Foundation.- *- * This program is distributed in the hope that it will be useful,- * but WITHOUT ANY WARRANTY; without even the implied warranty of- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the- * GNU General Public License for more details.- *- * You should have received a copy of the GNU General Public License- * along with this program. If not, see <http://www.gnu.org/licenses/>.- */-#ifndef __ASM_SETUP_H-#define __ASM_SETUP_H--#include <linux/types.h>--#endif
@@ -1,18 +0,0 @@-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */-/*- * Copyright (C) 2007-2009 Michal Simek <monstr@monstr.eu>- * Copyright (C) 2007-2009 PetaLogix- * Copyright (C) 2006 Atmark Techno, Inc.- *- * This file is subject to the terms and conditions of the GNU General Public- * License. See the file "COPYING" in the main directory of this archive- * for more details.- */--#ifndef _UAPI_ASM_MICROBLAZE_SETUP_H-#define _UAPI_ASM_MICROBLAZE_SETUP_H--# ifndef __ASSEMBLY__--# endif /* __ASSEMBLY__ */-#endif /* _UAPI_ASM_MICROBLAZE_SETUP_H */
@@ -1,15 +0,0 @@-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */-/*- * include/asm-xtensa/setup.h- *- * This file is subject to the terms and conditions of the GNU General Public- * License. See the file "COPYING" in the main directory of this archive- * for more details.- *- * Copyright (C) 2001 - 2005 Tensilica Inc.- */--#ifndef _XTENSA_SETUP_H-#define _XTENSA_SETUP_H--#endif
On Tue, Feb 14, 2023 at 08:49:01AM +0100, 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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/sparc/include/asm/setup.h | 6 +++++-
arch/sparc/include/uapi/asm/setup.h | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
On Tue, Feb 14, 2023 at 8:55 AM Alexandre Ghiti [off-list ref] wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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 Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens [off-list ref] wrote:
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
quoted
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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
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
From: Philippe Mathieu-Daudé <hidden> Date: 2023-02-14 09:08:06
On 14/2/23 08:49, Alexandre Ghiti wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/mips/include/asm/setup.h | 3 ++-
arch/mips/include/uapi/asm/setup.h | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
From: Philippe Mathieu-Daudé <hidden> Date: 2023-02-14 09:08:32
On 14/2/23 08:49, Alexandre Ghiti wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/alpha/include/asm/setup.h | 4 ++--
arch/alpha/include/uapi/asm/setup.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
From: Philippe Mathieu-Daudé <hidden> Date: 2023-02-14 09:09:41
On 14/2/23 08:49, Alexandre Ghiti wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/parisc/include/asm/setup.h | 7 +++++++
arch/parisc/include/uapi/asm/setup.h | 2 --
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 arch/parisc/include/asm/setup.h
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/sparc/include/asm/setup.h | 6 +++++-
arch/sparc/include/uapi/asm/setup.h | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens [off-list ref] wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
quoted
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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/parisc/include/asm/setup.h | 7 +++++++
arch/parisc/include/uapi/asm/setup.h | 2 --
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 arch/parisc/include/asm/setup.h
From: WANG Xuerui <kernel@xen0n.name> Date: 2023-02-14 10:17:46
On 2023/2/14 16:50, Sergey Shtylyov wrote:
On 2/14/23 10:49 AM, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/sparc/include/asm/setup.h | 6 +++++-
arch/sparc/include/uapi/asm/setup.h | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Date: 2023-02-14 10:40:15
On Tue, 2023-02-14 at 16:59 +0800, WANG Xuerui wrote:
On 2023/2/14 16:50, Sergey Shtylyov wrote:
quoted
On 2/14/23 10:49 AM, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/sparc/include/asm/setup.h | 6 +++++-
arch/sparc/include/uapi/asm/setup.h | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
From: Max Filippov <jcmvbkbc@gmail.com> Date: 2023-02-14 12:57:15
On Tue, Feb 14, 2023 at 12:01 AM Alexandre Ghiti [off-list ref] wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/xtensa/include/asm/setup.h | 17 +++++++++++++++++
arch/xtensa/include/uapi/asm/setup.h | 2 --
2 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 arch/xtensa/include/asm/setup.h
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
--
Thanks.
-- Max
On Tue, Feb 14, 2023 at 08:49:03AM +0100, Alexandre Ghiti wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2023-02-15 07:05:31
Alexandre Ghiti [off-list ref] writes:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
From: "Russell King (Oracle)" <linux@armlinux.org.uk> Date: 2023-02-15 13:00:48
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Looks good to me. What's the merge plan for this?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Looks good to me. What's the merge plan for this?
The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.
Arnd
Hi Arnd,
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann [off-list ref] wrote:
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Looks good to me. What's the merge plan for this?
The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.
Sorry for the response delay, I was waiting to see if Palmer would
merge my KASAN patchset in 6.3 (which he does): I have to admit that
fixing the command line size + the KASAN patchset would allow 6.3 to
run on syzkaller, which would be nice.
If I don't see this merged in 6.3, I'll send another round as you
suggested in 1 week now :)
Thanks!
Alex
On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Looks good to me. What's the merge plan for this?
The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.
Sorry for the response delay, I was waiting to see if Palmer would
merge my KASAN patchset in 6.3 (which he does): I have to admit that
fixing the command line size + the KASAN patchset would allow 6.3 to
run on syzkaller, which would be nice.
If I don't see this merged in 6.3, I'll send another round as you
suggested in 1 week now :)
Hi Alexandre,
I have no plans to still pick up the series for 6.3. The patches
all look fine to me, but it's clearly too late now. What is the
actual dependency for KASAN, do you just need a longer command
line or something else? If it's just the command line size,
I would suggest that Palmer can still pick up a oneline change
to increase it and refer to this thread in the changelog as a
reference for why it is not an actual UAPI break.
Arnd
On Thu, Feb 23, 2023 at 2:09 PM Arnd Bergmann [off-list ref] wrote:
On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
quoted
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Looks good to me. What's the merge plan for this?
The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.
Sorry for the response delay, I was waiting to see if Palmer would
merge my KASAN patchset in 6.3 (which he does): I have to admit that
fixing the command line size + the KASAN patchset would allow 6.3 to
run on syzkaller, which would be nice.
If I don't see this merged in 6.3, I'll send another round as you
suggested in 1 week now :)
Hi Alexandre,
I have no plans to still pick up the series for 6.3. The patches
all look fine to me, but it's clearly too late now. What is the
actual dependency for KASAN, do you just need a longer command
line or something else? If it's just the command line size,
I would suggest that Palmer can still pick up a oneline change
to increase it and refer to this thread in the changelog as a
reference for why it is not an actual UAPI break.
Indeed, we only need a longer command line size. I'll ask Palmer to do
that then, thanks!
Alex
On Thu, 23 Feb 2023 05:09:17 PST (-0800), Arnd Bergmann wrote:
On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
quoted
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann [off-list ref] wrote:
quoted
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
quoted
From: Palmer Dabbelt <redacted>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <redacted>
Looks good to me. What's the merge plan for this?
The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.
Sorry for the response delay, I was waiting to see if Palmer would
merge my KASAN patchset in 6.3 (which he does): I have to admit that
fixing the command line size + the KASAN patchset would allow 6.3 to
run on syzkaller, which would be nice.
If I don't see this merged in 6.3, I'll send another round as you
suggested in 1 week now :)
Hi Alexandre,
I have no plans to still pick up the series for 6.3. The patches
all look fine to me, but it's clearly too late now. What is the
actual dependency for KASAN, do you just need a longer command
line or something else? If it's just the command line size,
I would suggest that Palmer can still pick up a oneline change
to increase it and refer to this thread in the changelog as a
reference for why it is not an actual UAPI break.
Sorry for being slow here, I just queued up the original patch in the
RISC-V tree and intend on sending it for 6.3 -- the main worry was that
it's a uABi change and we're confident it's not. It's late, but I'd
prefer to have this as it should let us start running syzkaller now and
that'll probably find more bugs than this is likely to trigger.
https://lore.kernel.org/r/mhng-b5f934ff-a9bb-4c2b-9ba6-3ab68312077a@palmer-ri-x1c9a/
On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote:
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
quoted
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens [off-list ref] wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
quoted
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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was
some discussion of making this a Kconfig for everyone, which seems
reasonable to me -- our use case for this being extended is syzkaller,
but we're sort of just picking a value that's big enough for now and
running with it.
Probably best to get it out of uapi first, though, as that way at least
it's clear that it's not uABI.
quoted
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it
looks like you were planning on a v4 anyway (which I guess you now have
to do, given that I just added the issue to RISC-V).
On Thu, Mar 2, 2023 at 4:17 AM Palmer Dabbelt [off-list ref] wrote:
On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote:
quoted
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
quoted
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens [off-list ref] wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
quoted
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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was
some discussion of making this a Kconfig for everyone, which seems
reasonable to me -- our use case for this being extended is syzkaller,
but we're sort of just picking a value that's big enough for now and
running with it.
Probably best to get it out of uapi first, though, as that way at least
it's clear that it's not uABI.
quoted
quoted
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it
looks like you were planning on a v4 anyway (which I guess you now have
to do, given that I just added the issue to RISC-V).
From: "H. Peter Anvin" <hpa@zytor.com> Date: 2023-03-02 19:54:56
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt [off-list ref] wrote:
On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote:
quoted
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
quoted
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens [off-list ref] wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
quoted
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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it.
Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI.
quoted
quoted
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt [off-list ref] wrote:
quoted
On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote:
quoted
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
quoted
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens [off-list ref] wrote:
quoted
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
quoted
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.
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.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it.
Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI.
quoted
quoted
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
Is COMMAND_LINE_SIZE what you call the default length? Does that mean
that to you the patchset is wrong?
Thanks,
Alex
On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
On 3/2/23 20:50, H. Peter Anvin wrote:
quoted
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt [off-list ref] wrote:
quoted
quoted
quoted
quoted
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
Is COMMAND_LINE_SIZE what you call the default length? Does that mean
that to you the patchset is wrong?
On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header,
but instead (since bzImage format version 2.06) is communicated from
the kernel to the boot loader, which then knows how much data the
kernel will read (at most) from the command line.
Most x86 kernels these days are booted using UEFI, which I think has
no such interface, the firmware just passes the command line and a
length, but has no way of knowing if the kernel will truncate this.
I think that is the same as with any other architecture that passes
the command line through UEFI, DT or ATAGS, all of which use
length/value pairs.
Russell argued on IRC that this can be considered an ABI since a
boot loader may use its knowledge of the kernel's command line size
limit to reject long command lines. On the other hand, I don't
think that any boot loader actually does, they just trust that it
fits and don't have a good way of rejecting invalid configuration
other than truncating and/or warning.
One notable exception I found while looking through is the old
(pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE
as part of the structure definition. Apparently this was deprecated
22 years ago, so hopefully the remaining riscpc and footbridge
users have all upgraded their bootloaders.
The only other case I could find that might go wrong is
m68knommu with a few files copying a COMMAND_LINE_SIZE sized
buffer from flash into a kernel buffer:
arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size)
arch/m68k/coldfire/m5206.c-{
arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel)
arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */
arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size);
arch/m68k/coldfire/m5206.c- commandp[size-1] = 0;
arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */
Arnd
On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
quoted
On 3/2/23 20:50, H. Peter Anvin wrote:
quoted
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt [off-list ref] wrote:
quoted
quoted
quoted
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
Is COMMAND_LINE_SIZE what you call the default length? Does that mean
that to you the patchset is wrong?
On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header,
but instead (since bzImage format version 2.06) is communicated from
the kernel to the boot loader, which then knows how much data the
kernel will read (at most) from the command line.
Most x86 kernels these days are booted using UEFI, which I think has
no such interface, the firmware just passes the command line and a
length, but has no way of knowing if the kernel will truncate this.
I think that is the same as with any other architecture that passes
the command line through UEFI, DT or ATAGS, all of which use
length/value pairs.
Russell argued on IRC that this can be considered an ABI since a
boot loader may use its knowledge of the kernel's command line size
limit to reject long command lines. On the other hand, I don't
think that any boot loader actually does, they just trust that it
fits and don't have a good way of rejecting invalid configuration
other than truncating and/or warning.
One notable exception I found while looking through is the old
(pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE
as part of the structure definition. Apparently this was deprecated
22 years ago, so hopefully the remaining riscpc and footbridge
users have all upgraded their bootloaders.
The only other case I could find that might go wrong is
m68knommu with a few files copying a COMMAND_LINE_SIZE sized
buffer from flash into a kernel buffer:
arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size)
arch/m68k/coldfire/m5206.c-{
arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel)
arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */
arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size);
arch/m68k/coldfire/m5206.c- commandp[size-1] = 0;
arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */
I see, thanks your thorough explanation: I don't see this m64k issue as
a blocker (unless Geert disagrees but he already reviewed the m64k
patches), so I'll send the v5 now.
Thanks again,
Alex