Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

+PPC folks and Daniel W

On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@xxxxxxxxxx> wrote:
>
> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@xxxxxxxxxx> wrote:
> > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > when I started looking at replacing Android's out-of-tree implementation [2]
> >
> > Did anyone go read the common, reworked version of all this I
> > referenced that supports prepend and append. Here it is again[1].
> > Maybe I should have been more assertive there and said 'extend' is
> > ambiguous.
>
> I tried reading that, but (a) most of the series is not in the mailing list
> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> Right now the code in mainline does the opposite of what it's documented to
> do.

Actually, there is a newer version I found:

https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@xxxxxxxxx/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@xxxxxxxxx/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@xxxxxxxxx/

(Once again, there's some weird threading going on)

> > > with the upstream version, I noticed that the two behave significantly
> > > differently: Android follows the Kconfig help text of appending the
> > > bootloader arguments to the kernel command line, whereas upstream appends
> > > the kernel command line to the bootloader arguments. That is, except for
> > > the EFI stub, which follows the documented behaviour.
> > >
> > > I think the documented behaviour is more useful, so this patch series
> > > reworks the FDT code to follow that and updates the very recently merged
> > > arm64 idreg early command-line parsing as well.
> >
> > I can just as easily argue that the kernel having the last say makes
> > sense.
>
> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
> against both the documentation and the EFI stub implementation.

CMDLINE_FORCE is a complete override, not a merging of command lines.

> > Regardless, I'm pretty sure there's someone out there relying on current
> > behavior. What is the impact of this change to other arches?
>
> On arm64, I doubt it, as Android is the main user of this (where it's been
> supported for 9 years with the documented behaviour).
>
> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
> figured out. I think that's preferable to having divergent behaviour.
>
> As for other architectures, I think the ATAGs-based solution on arch/arm/
> gets it right:
>
>   static int __init parse_tag_cmdline(const struct tag *tag)
>   {
>   #if defined(CONFIG_CMDLINE_EXTEND)
>           strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>           strlcat(default_command_line, tag->u.cmdline.cmdline,
>                   COMMAND_LINE_SIZE);

The question is really whether any arm32 DT based platform depends on
the current behavior. RiscV could also be relying on current behavior.
Powerpc also uses the current behavior (and the documentation is also
wrong there). Changing the behavior in the FDT code means the powerpc
early PROM code and the FDT code do the opposite.

Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
Risc-V for 2 years. Then there's MIPS which has its own Kconfig
symbols for this and is its own kind of mess. Either we assume
existing users didn't really care about the order or we have to
support both prepend and append.

> For now I think we have two options for arm64: either fix the fdt code,
> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
> do you prefer?

Like anything copied across arches, I want someone to look at this
across all architectures and make this common instead of just copying
to new arches. The prepend/append series is the closest we've come.

Rob