From: Palmer Dabbelt <[email protected]>
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.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
include/{uapi => }/asm-generic/setup.h | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename include/{uapi => }/asm-generic/setup.h (100%)
diff --git a/include/uapi/asm-generic/setup.h b/include/asm-generic/setup.h
similarity index 100%
rename from include/uapi/asm-generic/setup.h
rename to include/asm-generic/setup.h
--
2.31.1.498.g6c1eba8ee3d-goog
On Fri, Apr 23, 2021 at 4:57 AM Palmer Dabbelt <[email protected]> wrote:
>
> From: Palmer Dabbelt <[email protected]>
>
> 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
On Fri, 23 Apr 2021 02:09:46 PDT (-0700), Arnd Bergmann wrote:
> On Fri, Apr 23, 2021 at 4:57 AM Palmer Dabbelt <[email protected]> wrote:
>>
>> From: Palmer Dabbelt <[email protected]>
>>
>> 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.