On Fri, Apr 23, 2021 at 4:57 AM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote:
>
> From: Palmer Dabbelt <palmerdabbelt@xxxxxxxxxx>
>
> I honestly have no idea if this is sane.
>
> 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 UABI 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.
>
> I couldn't think of a better way to ask about this then just sending the
> patch.
I think removing asm/setup.h from the uapi headers makes sense,
but then we should do it consistently for all architectures as far
as possible.
Most architectures either use the generic file or they provide their
own one-line version, so if we move them back, I would do it
for all.
The architectures that have additional contents in this file
are alpha, arm, and ia64. We I would leave those unchanged
in that case.
Arnd
