Le 24/03/2021 à 18:32, Rob Herring a écrit :
On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
<christophe.leroy@xxxxxxxxxx> wrote:
Le 09/03/2021 à 22:29, Daniel Walker a écrit :
On Tue, Mar 09, 2021 at 08:47:09AM +0100, Christophe Leroy wrote:
Le 09/03/2021 à 01:02, Daniel Walker a écrit :
This is a scripted mass convert of the config files to use
the new generic cmdline. There is a bit of a trim effect here.
It would seems that some of the config haven't been trimmed in
a while.
If you do that in a separate patch, you loose bisectability.
I think it would have been better to do things in a different way, more or less like I did in my series:
1/ Provide GENERIC cmdline at the same functionnality level as what is
spread in the different architectures
2/ Convert architectures to the generic with least churn.
3/ Add new features to the generic
You have to have the churn eventually, no matter how you do it. The only way you
don't have churn is if you never upgrade the feature set.
The bash script used to convert is as follows,
if [[ -z "$1" || -z "$2" ]]; then
echo "Two arguments are needed."
exit 1
fi
mkdir $1
cp $2 $1/.config
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config
This is not correct.
By default, on powerpc the provided command line is used only if the bootloader doesn't provide one.
Otherwise:
- the builtin command line is appended to the one provided by the bootloader
if CONFIG_CMDLINE_EXTEND is selected
- the builtin command line replaces to the one provided by the bootloader if
CONFIG_CMDLINE_FORCE is selected
I think my changes maintain most of this due to the override of
CONFIG_CMDLINE_PREPEND. This is an upgrade and the inflexibility in powerpc is
an example of why these changes were created in the first place.
"inflexibility in powerpc" : Can you elaborate ?
For example , say the default command line is "root=/dev/issblk0" from iss476
platform. And the bootloader adds "root=/dev/sda1"
The result is <prepend><bootloader><append>.
I'm still having hard time understanding the benefit of having both <prepend> and <append>.
Could you please provide a complete exemple from real life, ie what exactly the problem is and what
it solves ?
It doesn't matter. We already have both cases and 'extend' has meant either one.
What someone wants is policy and the kernel shouldn't be defining the policy.
Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
Let's only provide once CMDLINE as of today, and ask the user to select whether he wants it appended
or prepended or replacee. Then no need to change all existing config to rename CONFIG_CMDLINE into
either of the new ones.
That's the main difference between my series and Daniel's series. So I'll finish taking Will's
comment into account and we'll send out a v3 soon.
Thanks
Christophe
