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

Le 02/03/2021 à 15:56, Rob Herring a écrit :

On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
[off-list ref] wrote:

quoted

Le 01/03/2021 à 18:26, Rob Herring a écrit :

quoted

+PPC folks and Daniel W

On Mon, Mar 1, 2021 at 8:42 AM Will Deacon [off-list ref] wrote:

quoted

On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:

quoted

On Thu, Feb 25, 2021 at 6:59 AM Will Deacon [off-list ref] wrote:

quoted

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/ (local)
https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/ (local)
https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/ (local)

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.

quoted

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