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

[Christophe Leroy]

Le 01/03/2021 à 18:26, Rob Herring a écrit :
> +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/

This was seen as too much intrusive into powerpc.

I proposed an alternative at 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@xxxxxx/ but 
never got any feedback.


> (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

Christophe