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

[Christophe Leroy]

Le 02/03/2021 à 15:56, Rob Herring a écrit :
> On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
> <christophe.leroy at csgroup.eu> wrote:
>>
>>
>>
>> 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.
> 
> It looked like the main issue was string functions for KASAN?

This is one issue yes,

> 
> As far as being too complex, I think that will be needed if you look
> at all architectures and non-DT cases.

As far as I remember, I could't understand why we absolutely need to define the command line string 
in the common part of the code, leading to being obliged to use macros in order to allow the 
architecture to specify in which section it wants the string.

Why not leave the definition of the string to the architecture and just declare it in the common 
code, allowing the architecture to put it where it suits it and reducing opacity and allowing use of 
standard static inline functions instead of uggly macros.


> 
>> 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.
> 
> Didn't go to a list I subscribe to. In particular, if it had gone to
> DT list and into PW you would have gotten a reply from me.
> 

Sorry for that. Original series from Daniel 
(https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190319232448.45964-2-danielwa@cisco.com/) 
was sent only to linuxppc-dev list, and Michael suggested to also send it to linux-arch list, and I 
also always copy linux-kernel.

If there is new interest for that functionnality, I can try and rebase my series.

Christophe