On Fri, 23 Apr 2021 02:09:46 PDT (-0700), Arnd Bergmann wrote:
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.
Ya, makes sense. I just wanted to see if anyone had a reason for things being this way before I chased everything around.
The architectures that have additional contents in this file are alpha, arm, and ia64. We I would leave those unchanged in that case.
