lkml.org 
[lkml]   [2021]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"
    From
    Date


    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

    \
     
     \ /
      Last update: 2021-03-02 00:10    [W:4.302 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site