Messages in this thread | | | Subject | Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs" | From | Christophe Leroy <> | Date | Mon, 1 Mar 2021 18:45:28 +0100 |
| |
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@kernel.org> 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@kernel.org> 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@cisco.com/ > https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/ > https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
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@c-s.fr/ 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
| |