[PATCH v2 3/7] powerpc: convert config files to generic cmdline
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. 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 make ARCH=$1 O=$1 olddefconfig make ARCH=$1 O=$1 savedefconfig cp $1/defconfig $2 rm -Rf $1 Cc: xe-linux-exter...@cisco.com Signed-off-by: Daniel Walker --- arch/powerpc/configs/44x/fsp2_defconfig | 33 +-- arch/powerpc/configs/44x/iss476-smp_defconfig | 25 +++--- arch/powerpc/configs/44x/warp_defconfig | 17 +- arch/powerpc/configs/holly_defconfig | 13 arch/powerpc/configs/mvme5100_defconfig | 23 ++--- arch/powerpc/configs/skiroot_defconfig| 12 +++ arch/powerpc/configs/storcenter_defconfig | 18 -- 7 files changed, 66 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/configs/44x/fsp2_defconfig b/arch/powerpc/configs/44x/fsp2_defconfig index 30845ce0885a..4993db054589 100644 --- a/arch/powerpc/configs/44x/fsp2_defconfig +++ b/arch/powerpc/configs/44x/fsp2_defconfig @@ -1,8 +1,6 @@ -CONFIG_44x=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set -# CONFIG_FHANDLE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y @@ -13,24 +11,25 @@ CONFIG_BLK_DEV_INITRD=y # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set +# CONFIG_FHANDLE is not set CONFIG_KALLSYMS_ALL=y CONFIG_BPF_SYSCALL=y CONFIG_EMBEDDED=y CONFIG_PROFILING=y -CONFIG_OPROFILE=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_BLK_DEV_BSG is not set +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE_PREPEND="ip=on rw" +CONFIG_44x=y CONFIG_PPC_47x=y # CONFIG_EBONY is not set CONFIG_FSP2=y CONFIG_476FPE_ERR46=y -CONFIG_SWIOTLB=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y -CONFIG_CMDLINE="ip=on rw" # CONFIG_SUSPEND is not set -# CONFIG_PCI is not set +CONFIG_OPROFILE=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -47,14 +46,12 @@ CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_CFI_AMDSTD=y -CONFIG_MTD_PHYSMAP_OF=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=35000 # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y -# CONFIG_SATA_PMP is not set # CONFIG_ATA_SFF is not set CONFIG_NETDEVICES=y CONFIG_BONDING=m @@ -63,7 +60,6 @@ CONFIG_IBM_EMAC=m # CONFIG_SERIO is not set # CONFIG_VT is not set # CONFIG_LEGACY_PTYS is not set -# CONFIG_DEVMEM is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 @@ -72,6 +68,7 @@ CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set +# CONFIG_DEVMEM is not set CONFIG_I2C=y CONFIG_I2C_IBM_IIC=y CONFIG_PTP_1588_CLOCK=y @@ -107,6 +104,12 @@ CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y CONFIG_NLS_DEFAULT="n" +CONFIG_CRYPTO_CBC=y +CONFIG_CRYPTO_ECB=y +CONFIG_CRYPTO_PCBC=y +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_HW is not set CONFIG_XZ_DEC=y CONFIG_PRINTK_TIME=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=3 @@ -114,9 +117,3 @@ CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y CONFIG_MAGIC_SYSRQ=y CONFIG_DETECT_HUNG_TASK=y -CONFIG_CRYPTO_CBC=y -CONFIG_CRYPTO_ECB=y -CONFIG_CRYPTO_PCBC=y -CONFIG_CRYPTO_MD5=y -CONFIG_CRYPTO_DES=y -# CONFIG_CRYPTO_HW is not set diff --git a/arch/powerpc/configs/44x/iss476-smp_defconfig b/arch/powerpc/configs/44x/iss476-smp_defconfig index 2c3834eebca3..b8d97061517a 100644 --- a/arch/powerpc/configs/44x/iss476-smp_defconfig +++ b/arch/powerpc/configs/44x/iss476-smp_defconfig @@ -1,5 +1,3 @@ -CONFIG_44x=y -CONFIG_SMP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_LOG_BUF_SHIFT=14 @@ -7,20 +5,22 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_KALLSYMS_ALL=y CONFIG_PROFILING=y -CONFIG_OPROFILE=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_BLK_DEV_BSG is not set +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE_PREPEND="root=/dev/issblk0" +CONFIG_44x=y +CONFIG_SMP=y CONFIG_PPC_47x=y # CONFIG_EBONY is not set CONFIG_ISS4xx=y CONFIG_HZ_100=y CONFIG_MATH_EMULATION=y CONFIG_IRQ_ALL_CPUS=y -CONFIG_CMDLINE="root=/dev/issblk0" -# CONFIG_PCI is not set CONFIG_ADVANCED_OPTIONS=y CONFIG_DYNAMIC_MEMSTART=y +CONFIG_OPROFILE=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -34,7 +34,6 @@ CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_CFI_AMDSTD=y -CONFIG_MTD_PHYSMAP_OF=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=35000 # CONFIG_INPUT is not set @@ -57,13 +56,13 @@ CONFIG_PROC_KCORE=y
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
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 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 make ARCH=$1 O=$1 olddefconfig make ARCH=$1 O=$1 savedefconfig cp $1/defconfig $2 rm -Rf $1 Cc: xe-linux-exter...@cisco.com Signed-off-by: Daniel Walker --- arch/powerpc/configs/44x/fsp2_defconfig | 33 +-- arch/powerpc/configs/44x/iss476-smp_defconfig | 25 +++--- arch/powerpc/configs/44x/warp_defconfig | 17 +- arch/powerpc/configs/holly_defconfig | 13 arch/powerpc/configs/mvme5100_defconfig | 23 ++--- arch/powerpc/configs/skiroot_defconfig| 12 +++ arch/powerpc/configs/storcenter_defconfig | 18 -- 7 files changed, 66 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/configs/44x/fsp2_defconfig b/arch/powerpc/configs/44x/fsp2_defconfig index 30845ce0885a..4993db054589 100644 --- a/arch/powerpc/configs/44x/fsp2_defconfig +++ b/arch/powerpc/configs/44x/fsp2_defconfig @@ -1,8 +1,6 @@ -CONFIG_44x=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set -# CONFIG_FHANDLE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y @@ -13,24 +11,25 @@ CONFIG_BLK_DEV_INITRD=y # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set +# CONFIG_FHANDLE is not set CONFIG_KALLSYMS_ALL=y CONFIG_BPF_SYSCALL=y CONFIG_EMBEDDED=y CONFIG_PROFILING=y -CONFIG_OPROFILE=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_BLK_DEV_BSG is not set +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE_PREPEND="ip=on rw" +CONFIG_44x=y CONFIG_PPC_47x=y # CONFIG_EBONY is not set CONFIG_FSP2=y CONFIG_476FPE_ERR46=y -CONFIG_SWIOTLB=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y -CONFIG_CMDLINE="ip=on rw" # CONFIG_SUSPEND is not set -# CONFIG_PCI is not set +CONFIG_OPROFILE=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -47,14 +46,12 @@ CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_CFI_AMDSTD=y -CONFIG_MTD_PHYSMAP_OF=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=35000 # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y -# CONFIG_SATA_PMP is not set # CONFIG_ATA_SFF is not set CONFIG_NETDEVICES=y CONFIG_BONDING=m @@ -63,7 +60,6 @@ CONFIG_IBM_EMAC=m # CONFIG_SERIO is not set # CONFIG_VT is not set # CONFIG_LEGACY_PTYS is not set -# CONFIG_DEVMEM is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 @@ -72,6 +68,7 @@ CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set +# CONFIG_DEVMEM is not set CONFIG_I2C=y CONFIG_I2C_IBM_IIC=y CONFIG_PTP_1588_CLOCK=y @@ -107,6 +104,12 @@ CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y CONFIG_NLS_DEFAULT="n" +CONFIG_CRYPTO_CBC=y +CONFIG_CRYPTO_ECB=y +CONFIG_CRYPTO_PCBC=y +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_HW is not set CONFIG_XZ_DEC=y CONFIG_PRINTK_TIME=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=3 @@ -114,9 +117,3 @@ CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y CONFIG_MAGIC_SYSRQ=y CONFIG_DETECT_HUNG_TASK=y -CONFIG_CRYPTO_CBC=y -CONFIG_CRYPTO_ECB=y -CONFIG_CRYPTO_PCBC=y -CONFIG_CRYPTO_MD5=y -CONFIG_CRYPTO_DES=y -# CONFIG_CRYPTO_HW is not set diff --git a/arch/powerpc/configs/44x/iss476-smp_defconfig b/arch/powerpc/configs/44x/iss476-smp_defconfig index 2c3834eebca3..b8d97061517a 100644 --- a/arch/powerpc/configs/44x/iss476-smp_defconfig +++ b/arch/powerpc/configs/44x/iss476-smp_defconfig @@ -1,5 +1,3 @@ -CONFIG_44x=y -CONFIG_SMP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_LOG_BUF_SHIFT=14 @@ -7,20 +5,22 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_EXP
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
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. For example , say the default command line is "root=/dev/issblk0" from iss476 platform. And the bootloader adds "root=/dev/sda1" The result is . Then you have, root=/dev/issblk0 root=/dev/sda1 and the bootloader has precedent over the default command line. So root= in the above cases is defined by the bootloader. The only issue would be if a person wants to override the default command line with an unrelated bootloader command line. I don't know how many people do this, but I doubt it's many. Can you think of any use cases like this? I would imagine there are many more people who have to entirely duplicate the default command line in the boot loader when they really just want to change a single part of it like the root= device or console device or speed. Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
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 . I'm still having hard time understanding the benefit of having both and . Could you please provide a complete exemple from real life, ie what exactly the problem is and what it solves ? Then you have, root=/dev/issblk0 root=/dev/sda1 and the bootloader has precedent over the default command line. So root= in the above cases is defined by the bootloader. The only issue would be if a person wants to override the default command line with an unrelated bootloader command line. I don't know how many people do this, but I doubt it's many. Can you think of any use cases like this? I would imagine there are many more people who have to entirely duplicate the default command line in the boot loader when they really just want to change a single part of it like the root= device or console device or speed. Daniel Christophe
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy 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 . > > > I'm still having hard time understanding the benefit of having both > and . > 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. Rob
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
Le 24/03/2021 à 18:32, Rob Herring a écrit : On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy 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 . I'm still having hard time understanding the benefit of having both and . 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
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Thu, Mar 25, 2021 at 6:06 AM Christophe Leroy wrote: > > > > Le 24/03/2021 à 18:32, Rob Herring a écrit : > > On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy > > 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 . > >> > >> > >> I'm still having hard time understanding the benefit of having both > >> and . > >> 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. Well, I wasn't thinking about that part of it, but yes as long as no arch currently needs that. > 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. Great. Rob
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Wed, Mar 24, 2021 at 05:59:59PM +0100, Christophe Leroy wrote: > > 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 ? the prom environment. > > > > For example , say the default command line is "root=/dev/issblk0" from > > iss476 > > platform. And the bootloader adds "root=/dev/sda1" > > > > The result is . > > > I'm still having hard time understanding the benefit of having both > and . > Could you please provide a complete exemple from real life, ie what exactly > the problem is and what it solves ? Say the boot loader of an old product is released with a command line of "root=/dev/sda" and per the needs of the company or product the boot loader can not be upgraded to change this command line. To change this behavior you would need append or EXTEND. Below I detail an example of PREPEND due to your list question. > > > > Then you have, > > > > root=/dev/issblk0 root=/dev/sda1 > > > > and the bootloader has precedent over the default command line. So root= in > > the > > above cases is defined by the bootloader. A person could input a command line into a boot loader, and it would override the PREPEND values. Can you imagine you have a default command line which makes root=/dev/issblk0 , but that doesn't work for you testing purpose. So you input into the boot loader root=/dev/sda1 , since you have the default input in the bootloader OVERRIDEABLE you can do this without re-compiling and just input the single root= command into the bootloader. Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > 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. It doesn't solve the needs of Cisco, I've stated many times your changes have little value. Please stop submitting them. Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker wrote: > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > 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. > > It doesn't solve the needs of Cisco, I've stated many times your changes have > little value. Please stop submitting them. Can you please outline what those needs are which aren't met? Rob
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote: > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > 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. > > It doesn't solve the needs of Cisco, I've stated many times your changes have > little value. Please stop submitting them. FWIW, they're useful for arm64 and I will gladly review the updated series. I don't think asking people to stop submitting patches is ever the right answer. Please don't do that. Will
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote: > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker wrote: > > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > 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. > > > > It doesn't solve the needs of Cisco, I've stated many times your changes > > have > > little value. Please stop submitting them. > > Can you please outline what those needs are which aren't met? append AND prepend at the same time on all architectures. Christophe doesn't understand the need, and hence tries to minimize the feature set which is incompatible with Cisco needs and all the other out of tree users. Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Mon, Mar 29, 2021 at 11:07:51AM +0100, Will Deacon wrote: > On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote: > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > 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. > > > > It doesn't solve the needs of Cisco, I've stated many times your changes > > have > > little value. Please stop submitting them. > > FWIW, they're useful for arm64 and I will gladly review the updated series. > > I don't think asking people to stop submitting patches is ever the right > answer. Please don't do that. Why ? It's me nacking his series, is that not allowed anymore ? Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker wrote: > > On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote: > > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker wrote: > > > > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > > > 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. > > > > > > It doesn't solve the needs of Cisco, I've stated many times your changes > > > have > > > little value. Please stop submitting them. > > > > Can you please outline what those needs are which aren't met? > > append AND prepend at the same time on all architectures. Christophe doesn't > understand the need, and hence tries to minimize the feature set which is > incompatible with Cisco needs and all the other out of tree users. Okay, but that's never been a feature in upstream. For upstream, we refactor first and add features 2nd. In this case, the difference is largely the kconfig and it would be better to not change the options twice, but that's not a blocker for taking the refactoring. You won't find a maintainer that's going to take adding a feature over cleanups and unification. Rob
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Tue, Mar 30, 2021 at 03:13:04PM -0500, Rob Herring wrote: > On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker wrote: > > > > On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote: > > > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker wrote: > > > > > > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > > > > > 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. > > > > > > > > It doesn't solve the needs of Cisco, I've stated many times your > > > > changes have > > > > little value. Please stop submitting them. > > > > > > Can you please outline what those needs are which aren't met? > > > > append AND prepend at the same time on all architectures. Christophe doesn't > > understand the need, and hence tries to minimize the feature set which is > > incompatible with Cisco needs and all the other out of tree users. > > Okay, but that's never been a feature in upstream. For upstream, we > refactor first and add features 2nd. In this case, the difference is > largely the kconfig and it would be better to not change the options > twice, but that's not a blocker for taking the refactoring. You won't > find a maintainer that's going to take adding a feature over cleanups > and unification. It kind of is a feature in upstream, it's a matter of opinion. Some platform used append and some use prepend, and it's likely because the maintainers needed one or the other for development. I'm not sure why you think I can't add the features in one go. It would be horrid to take Christophe's changes, then have to do basically all the same work a second time which is what Christophe's changes would force me to do. Say for example I implement this change only on one architecture. In that case the maintainer would be accepting a feature enhancement , but there would be no stopping it. I shouldn't have to go two strokes on one architecture, but each change I'm making is essentially a single architecture. They can go in all together or one at a time. Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Tue, Mar 30, 2021 at 10:35:21AM -0700, Daniel Walker wrote: > On Mon, Mar 29, 2021 at 11:07:51AM +0100, Will Deacon wrote: > > On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote: > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > > > 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. > > > > > > It doesn't solve the needs of Cisco, I've stated many times your changes > > > have > > > little value. Please stop submitting them. > > > > FWIW, they're useful for arm64 and I will gladly review the updated series. > > > > I don't think asking people to stop submitting patches is ever the right > > answer. Please don't do that. > > Why ? It's me nacking his series, is that not allowed anymore ? If you're that way inclined then you can "nack" whatever you want, but please allow the rest of us to continue reviewing the patches. You don't have any basis on which to veto other people's contributions and so demanding that somebody stops posting code is neither constructive nor meaningful. Will
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Wed, Mar 31, 2021 at 12:52:19PM +0100, Will Deacon wrote: > On Tue, Mar 30, 2021 at 10:35:21AM -0700, Daniel Walker wrote: > > On Mon, Mar 29, 2021 at 11:07:51AM +0100, Will Deacon wrote: > > > On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote: > > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > > > > > 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. > > > > > > > > It doesn't solve the needs of Cisco, I've stated many times your > > > > changes have > > > > little value. Please stop submitting them. > > > > > > FWIW, they're useful for arm64 and I will gladly review the updated > > > series. > > > > > > I don't think asking people to stop submitting patches is ever the right > > > answer. Please don't do that. > > > > Why ? It's me nacking his series, is that not allowed anymore ? > > If you're that way inclined then you can "nack" whatever you want, but > please allow the rest of us to continue reviewing the patches. You don't > have any basis on which to veto other people's contributions and so > demanding that somebody stops posting code is neither constructive nor > meaningful. I understand , but that's not what's happening. I've dealt with Christophe on these changes repeatedly, and he's demonstrated he doesn't understand the feature set or the motivation of the changes. I've tried to work with him in the past, but it doesn't work unless he's giving me comments on my changes. His changes don't solve Cisco problems, and likely never will regardless of feedback. Maybe that could change, but I don't see that happening. Daniel
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Tue, Mar 30, 2021 at 6:31 PM Daniel Walker wrote: > > On Tue, Mar 30, 2021 at 03:13:04PM -0500, Rob Herring wrote: > > On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker wrote: > > > > > > On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote: > > > > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker > > > > wrote: > > > > > > > > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > > > > > > > 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. > > > > > > > > > > It doesn't solve the needs of Cisco, I've stated many times your > > > > > changes have > > > > > little value. Please stop submitting them. > > > > > > > > Can you please outline what those needs are which aren't met? > > > > > > append AND prepend at the same time on all architectures. Christophe > > > doesn't > > > understand the need, and hence tries to minimize the feature set which is > > > incompatible with Cisco needs and all the other out of tree users. > > > > Okay, but that's never been a feature in upstream. For upstream, we > > refactor first and add features 2nd. In this case, the difference is > > largely the kconfig and it would be better to not change the options > > twice, but that's not a blocker for taking the refactoring. You won't > > find a maintainer that's going to take adding a feature over cleanups > > and unification. > > It kind of is a feature in upstream, it's a matter of opinion. Some platform > used append and some use prepend, and it's likely because the maintainers > needed > one or the other for development. Which arch/platform upstream does both prepend and append at the same time? > I'm not sure why you think I can't add the features in one go. It would be > horrid to take Christophe's changes, then have to do basically all the same > work > a second time which is what Christophe's changes would force me to do. I didn't say it couldn't be done. In fact, I said it would be better all at once: "it would be better to not change the options twice" But both of you ignoring comments and continuing to post competing series is not going to get us there. TBC, I think Christophe's series is much closer to being in shape to merge upstream. > Say for example I implement this change only on one architecture. In that case > the maintainer would be accepting a feature enhancement , but there would be > no > stopping it. I shouldn't have to go two strokes on one architecture, but each > change I'm making is essentially a single architecture. They can go in all > together or one at a time. Features do get implemented all the time on one arch. And then maybe a 2nd and 3rd. At some point we decide no more copying, it needs to be common and refactored. We're at that point for cmdline handling IMO. Rob
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
On Thu, Apr 01, 2021 at 03:08:04PM -0500, Rob Herring wrote: > On Tue, Mar 30, 2021 at 6:31 PM Daniel Walker wrote: > > > > On Tue, Mar 30, 2021 at 03:13:04PM -0500, Rob Herring wrote: > > > On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker wrote: > > > > > > > > On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote: > > > > > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker > > > > > wrote: > > > > > > > > > > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote: > > > > > > > > > > > > > > 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. > > > > > > > > > > > > It doesn't solve the needs of Cisco, I've stated many times your > > > > > > changes have > > > > > > little value. Please stop submitting them. > > > > > > > > > > Can you please outline what those needs are which aren't met? > > > > > > > > append AND prepend at the same time on all architectures. Christophe > > > > doesn't > > > > understand the need, and hence tries to minimize the feature set which > > > > is > > > > incompatible with Cisco needs and all the other out of tree users. > > > > > > Okay, but that's never been a feature in upstream. For upstream, we > > > refactor first and add features 2nd. In this case, the difference is > > > largely the kconfig and it would be better to not change the options > > > twice, but that's not a blocker for taking the refactoring. You won't > > > find a maintainer that's going to take adding a feature over cleanups > > > and unification. > > > > It kind of is a feature in upstream, it's a matter of opinion. Some platform > > used append and some use prepend, and it's likely because the maintainers > > needed > > one or the other for development. > > Which arch/platform upstream does both prepend and append at the same time? None do it at the same time, however x86 and mips have switched between the two. > > I'm not sure why you think I can't add the features in one go. It would be > > horrid to take Christophe's changes, then have to do basically all the same > > work > > a second time which is what Christophe's changes would force me to do. > > I didn't say it couldn't be done. In fact, I said it would be better > all at once: "it would be better to not change the options twice" > > But both of you ignoring comments and continuing to post competing > series is not going to get us there. TBC, I think Christophe's series > is much closer to being in shape to merge upstream. I'm not the one ignoring comments .. I've taken a number of comments from Christophe, but he still submits his own series.. Christophe series doesn't look good to me.. I suspect you like it cause it deletes lines from of. > > Say for example I implement this change only on one architecture. In that > > case > > the maintainer would be accepting a feature enhancement , but there would > > be no > > stopping it. I shouldn't have to go two strokes on one architecture, but > > each > > change I'm making is essentially a single architecture. They can go in all > > together or one at a time. > > Features do get implemented all the time on one arch. And then maybe a > 2nd and 3rd. At some point we decide no more copying, it needs to be > common and refactored. We're at that point for cmdline handling IMO. I don't think it can be done with one series all at once .. Daniel