[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 at 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 at 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