On 3/3/23 17:40, Arnd Bergmann wrote:
On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
On 3/2/23 20:50, H. Peter Anvin wrote:
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote:
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
Arnd
