[v2,3/7] powerpc: convert config files to generic cmdline

Message ID	20210309000247.2989531-4-danielwa@cisco.com (mailing list archive)
State	Superseded
Headers	show Return-Path: <linux-mips-owner@kernel.org> From: Daniel Walker <danielwa@cisco.com> To: Will Deacon <will@kernel.org>, Christophe Leroy <christophe.leroy@csgroup.eu>, Rob Herring <robh@kernel.org>, Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>, Andrew Morton <akpm@linux-foundation.org>, x86@kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, xe-linux-external@cisco.com Cc: Michael Ellerman <mpe@ellerman.id.au>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Paul Mackerras <paulus@samba.org>, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/7] powerpc: convert config files to generic cmdline Date: Mon, 8 Mar 2021 16:02:39 -0800 Message-Id: <20210309000247.2989531-4-danielwa@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk
Series	[v2,1/7] CMDLINE: add generic builtin command line \| expand [v2,1/7] CMDLINE: add generic builtin command line [v2,2/7] CMDLINE: drivers: of: ifdef out cmdline section [v2,3/7] powerpc: convert config files to generic cmdline [v2,4/7] CMDLINE: powerpc: convert to generic builtin command line [v2,5/7] mips: convert config files to generic cmdline [v2,6/7] CMDLINE: mips: convert to generic builtin command line [v2,7/7] CMDLINE: x86: convert to generic builtin command line

Daniel Walker (danielwa) March 9, 2021, 12:02 a.m. UTC

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-external@cisco.com
Signed-off-by: Daniel Walker <danielwa@cisco.com>
---
 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(-)

Christophe Leroy March 9, 2021, 7:47 a.m. UTC | #1

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-external@cisco.com
> Signed-off-by: Daniel Walker <danielwa@cisco.com>
> ---
>   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
>   CONFIG_TMPFS=y
>   CONFIG_CRAMFS=y
>   # CONFIG_NETWORK_FILESYSTEMS is not set
> -CONFIG_DEBUG_INFO=y
> -CONFIG_MAGIC_SYSRQ=y
> -CONFIG_DETECT_HUNG_TASK=y
> -CONFIG_PPC_EARLY_DEBUG=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
> +CONFIG_DEBUG_INFO=y
> +CONFIG_MAGIC_SYSRQ=y
> +CONFIG_DETECT_HUNG_TASK=y
> +CONFIG_PPC_EARLY_DEBUG=y
> diff --git a/arch/powerpc/configs/44x/warp_defconfig b/arch/powerpc/configs/44x/warp_defconfig
> index 47252c2d7669..d2e4bbe1492c 100644
> --- a/arch/powerpc/configs/44x/warp_defconfig
> +++ b/arch/powerpc/configs/44x/warp_defconfig
> @@ -1,4 +1,3 @@
> -CONFIG_44x=y
>   CONFIG_LOCALVERSION="-pika"
>   # CONFIG_LOCALVERSION_AUTO is not set
>   CONFIG_SYSVIPC=y
> @@ -7,15 +6,16 @@ CONFIG_IKCONFIG_PROC=y
>   CONFIG_LOG_BUF_SHIFT=14
>   CONFIG_BLK_DEV_INITRD=y
>   CONFIG_EXPERT=y
> -CONFIG_MODULES=y
> -CONFIG_MODULE_UNLOAD=y
> -# CONFIG_BLK_DEV_BSG is not set
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE_PREPEND="ip=on"
> +CONFIG_44x=y
>   # CONFIG_EBONY is not set
>   CONFIG_WARP=y
>   CONFIG_PPC4xx_GPIO=y
>   CONFIG_HZ_1000=y
> -CONFIG_CMDLINE="ip=on"
> -# CONFIG_PCI is not set
> +CONFIG_MODULES=y
> +CONFIG_MODULE_UNLOAD=y
> +# CONFIG_BLK_DEV_BSG is not set
>   CONFIG_NET=y
>   CONFIG_PACKET=y
>   CONFIG_UNIX=y
> @@ -31,7 +31,6 @@ CONFIG_MTD_CMDLINE_PARTS=y
>   CONFIG_MTD_BLOCK=y
>   CONFIG_MTD_CFI=y
>   CONFIG_MTD_CFI_AMDSTD=y
> -CONFIG_MTD_PHYSMAP_OF=y
>   CONFIG_MTD_RAW_NAND=y
>   CONFIG_MTD_NAND_NDFC=y
>   CONFIG_MTD_UBI=y
> @@ -88,9 +87,9 @@ CONFIG_NLS_UTF8=y
>   CONFIG_CRC_CCITT=y
>   CONFIG_CRC_T10DIF=y
>   CONFIG_PRINTK_TIME=y
> +# CONFIG_DEBUG_BUGVERBOSE is not set
>   CONFIG_DEBUG_INFO=y
> -CONFIG_DEBUG_FS=y
>   CONFIG_MAGIC_SYSRQ=y
> +CONFIG_DEBUG_FS=y
>   CONFIG_DETECT_HUNG_TASK=y
>   # CONFIG_SCHED_DEBUG is not set
> -# CONFIG_DEBUG_BUGVERBOSE is not set
> diff --git a/arch/powerpc/configs/holly_defconfig b/arch/powerpc/configs/holly_defconfig
> index 271daff47d1d..98c0644e80b4 100644
> --- a/arch/powerpc/configs/holly_defconfig
> +++ b/arch/powerpc/configs/holly_defconfig
> @@ -4,17 +4,18 @@ CONFIG_HIGH_RES_TIMERS=y
>   CONFIG_LOG_BUF_SHIFT=14
>   CONFIG_BLK_DEV_INITRD=y
>   CONFIG_EXPERT=y
> -CONFIG_MODULES=y
> -# CONFIG_BLK_DEV_BSG is not set
> -CONFIG_PARTITION_ADVANCED=y
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE_PREPEND="console=ttyS0,115200"
>   # CONFIG_PPC_CHRP is not set
>   # CONFIG_PPC_PMAC is not set
>   CONFIG_EMBEDDED6xx=y
>   CONFIG_PPC_HOLLY=y
>   CONFIG_GEN_RTC=y
> -CONFIG_BINFMT_MISC=y
> -CONFIG_CMDLINE="console=ttyS0,115200"
>   # CONFIG_SECCOMP is not set
> +CONFIG_MODULES=y
> +# CONFIG_BLK_DEV_BSG is not set
> +CONFIG_PARTITION_ADVANCED=y
> +CONFIG_BINFMT_MISC=y
>   CONFIG_NET=y
>   CONFIG_PACKET=y
>   CONFIG_UNIX=y
> @@ -53,8 +54,8 @@ CONFIG_PROC_KCORE=y
>   CONFIG_TMPFS=y
>   CONFIG_NFS_FS=y
>   CONFIG_ROOT_NFS=y
> +# CONFIG_DEBUG_BUGVERBOSE is not set
>   CONFIG_MAGIC_SYSRQ=y
>   # CONFIG_SCHED_DEBUG is not set
> -# CONFIG_DEBUG_BUGVERBOSE is not set
>   CONFIG_XMON=y
>   CONFIG_XMON_DEFAULT=y
> diff --git a/arch/powerpc/configs/mvme5100_defconfig b/arch/powerpc/configs/mvme5100_defconfig
> index 1fed6be95d53..884a3e0defde 100644
> --- a/arch/powerpc/configs/mvme5100_defconfig
> +++ b/arch/powerpc/configs/mvme5100_defconfig
> @@ -11,16 +11,17 @@ CONFIG_LOG_BUF_SHIFT=14
>   # CONFIG_NET_NS is not set
>   CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>   # CONFIG_COMPAT_BRK is not set
> -CONFIG_MODULES=y
> -CONFIG_MODULE_UNLOAD=y
> -# CONFIG_BLK_DEV_BSG is not set
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE_PREPEND="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
>   # CONFIG_PPC_CHRP is not set
>   # CONFIG_PPC_PMAC is not set
>   CONFIG_EMBEDDED6xx=y
>   CONFIG_MVME5100=y
>   CONFIG_KVM_GUEST=y
>   CONFIG_HZ_100=y
> -CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
> +CONFIG_MODULES=y
> +CONFIG_MODULE_UNLOAD=y
> +# CONFIG_BLK_DEV_BSG is not set
>   # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>   # CONFIG_COMPACTION is not set
>   CONFIG_NET=y
> @@ -108,13 +109,6 @@ CONFIG_NLS_CODEPAGE_437=m
>   CONFIG_NLS_CODEPAGE_932=m
>   CONFIG_NLS_ISO8859_1=m
>   CONFIG_NLS_UTF8=m
> -CONFIG_CRC_CCITT=m
> -CONFIG_CRC_T10DIF=y
> -CONFIG_XZ_DEC=y
> -CONFIG_MAGIC_SYSRQ=y
> -CONFIG_DEBUG_KERNEL=y
> -CONFIG_DETECT_HUNG_TASK=y
> -CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=20
>   CONFIG_CRYPTO_CBC=y
>   CONFIG_CRYPTO_PCBC=m
>   CONFIG_CRYPTO_MD5=y
> @@ -125,3 +119,10 @@ CONFIG_CRYPTO_DES=y
>   CONFIG_CRYPTO_SERPENT=m
>   CONFIG_CRYPTO_TWOFISH=m
>   CONFIG_CRYPTO_DEFLATE=m
> +CONFIG_CRC_CCITT=m
> +CONFIG_CRC_T10DIF=y
> +CONFIG_XZ_DEC=y
> +CONFIG_MAGIC_SYSRQ=y
> +CONFIG_DEBUG_KERNEL=y
> +CONFIG_DETECT_HUNG_TASK=y
> +CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=20
> diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
> index b806a5d3a695..5e11995508d7 100644
> --- a/arch/powerpc/configs/skiroot_defconfig
> +++ b/arch/powerpc/configs/skiroot_defconfig
> @@ -26,6 +26,8 @@ CONFIG_PERF_EVENTS=y
>   # CONFIG_SLAB_MERGE_DEFAULT is not set
>   CONFIG_SLAB_FREELIST_RANDOM=y
>   CONFIG_SLAB_FREELIST_HARDENED=y
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE_PREPEND="console=tty0 console=hvc0 ipr.fast_reboot=1 quiet"
>   CONFIG_PPC64=y
>   CONFIG_ALTIVEC=y
>   CONFIG_VSX=y
> @@ -42,14 +44,11 @@ CONFIG_KEXEC=y
>   CONFIG_KEXEC_FILE=y
>   CONFIG_PRESERVE_FA_DUMP=y
>   CONFIG_IRQ_ALL_CPUS=y
> -CONFIG_NUMA=y
>   CONFIG_PPC_64K_PAGES=y
>   CONFIG_SCHED_SMT=y
> -CONFIG_CMDLINE="console=tty0 console=hvc0 ipr.fast_reboot=1 quiet"
> -# CONFIG_SECCOMP is not set
>   # CONFIG_PPC_MEM_KEYS is not set
>   CONFIG_JUMP_LABEL=y
> -CONFIG_STRICT_KERNEL_RWX=y
> +# CONFIG_SECCOMP is not set
>   CONFIG_MODULES=y
>   CONFIG_MODULE_UNLOAD=y
>   CONFIG_MODULE_SIG_FORCE=y
> @@ -80,7 +79,6 @@ CONFIG_BLK_DEV_NVME=m
>   CONFIG_NVME_MULTIPATH=y
>   CONFIG_EEPROM_AT24=m
>   # CONFIG_CXL is not set
> -# CONFIG_OCXL is not set
>   CONFIG_BLK_DEV_SD=m
>   CONFIG_BLK_DEV_SR=m
>   CONFIG_CHR_DEV_SG=m
> @@ -199,7 +197,6 @@ CONFIG_PHYLIB=y
>   CONFIG_INPUT_EVDEV=y
>   CONFIG_INPUT_MISC=y
>   # CONFIG_SERIO_SERPORT is not set
> -# CONFIG_DEVMEM is not set
>   CONFIG_SERIAL_8250=y
>   CONFIG_SERIAL_8250_CONSOLE=y
>   CONFIG_IPMI_HANDLER=y
> @@ -207,9 +204,10 @@ CONFIG_IPMI_DEVICE_INTERFACE=y
>   CONFIG_IPMI_POWERNV=y
>   CONFIG_IPMI_WATCHDOG=y
>   CONFIG_HW_RANDOM=y
> +# CONFIG_DEVMEM is not set
> +# CONFIG_DEVPORT is not set
>   CONFIG_TCG_TPM=y
>   CONFIG_TCG_TIS_I2C_NUVOTON=y
> -# CONFIG_DEVPORT is not set
>   CONFIG_I2C=y
>   # CONFIG_I2C_COMPAT is not set
>   CONFIG_I2C_CHARDEV=y
> diff --git a/arch/powerpc/configs/storcenter_defconfig b/arch/powerpc/configs/storcenter_defconfig
> index 47dcfaddc1ac..17a17b8ae160 100644
> --- a/arch/powerpc/configs/storcenter_defconfig
> +++ b/arch/powerpc/configs/storcenter_defconfig
> @@ -2,18 +2,19 @@ CONFIG_SYSVIPC=y
>   CONFIG_LOG_BUF_SHIFT=14
>   CONFIG_EXPERT=y
>   # CONFIG_KALLSYMS is not set
> -CONFIG_MODULES=y
> -CONFIG_MODULE_UNLOAD=y
> -# CONFIG_BLK_DEV_BSG is not set
> -CONFIG_PARTITION_ADVANCED=y
> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE_PREPEND="console=ttyS0,115200"
>   # CONFIG_PPC_CHRP is not set
>   # CONFIG_PPC_PMAC is not set
>   CONFIG_EMBEDDED6xx=y
>   CONFIG_STORCENTER=y
>   CONFIG_HZ_100=y
> -CONFIG_BINFMT_MISC=y
> -CONFIG_CMDLINE="console=ttyS0,115200"
>   # CONFIG_SECCOMP is not set
> +CONFIG_MODULES=y
> +CONFIG_MODULE_UNLOAD=y
> +# CONFIG_BLK_DEV_BSG is not set
> +CONFIG_PARTITION_ADVANCED=y
> +CONFIG_BINFMT_MISC=y
>   CONFIG_NET=y
>   CONFIG_PACKET=m
>   CONFIG_UNIX=y
> @@ -35,7 +36,6 @@ CONFIG_BLK_DEV_SD=y
>   CONFIG_BLK_DEV_SR=y
>   CONFIG_SCSI_SPI_ATTRS=y
>   CONFIG_ATA=y
> -CONFIG_PATA_VIA=y
>   CONFIG_MD=y
>   CONFIG_BLK_DEV_MD=y
>   CONFIG_MD_LINEAR=y
> @@ -44,16 +44,13 @@ CONFIG_MD_RAID1=y
>   CONFIG_MD_RAID456=y
>   CONFIG_NETDEVICES=y
>   CONFIG_DUMMY=m
> -CONFIG_R8169=y
>   # CONFIG_INPUT is not set
>   # CONFIG_SERIO is not set
>   # CONFIG_VT is not set
>   CONFIG_SERIAL_8250=y
>   CONFIG_SERIAL_8250_CONSOLE=y
> -# CONFIG_SERIAL_8250_PCI is not set
>   CONFIG_SERIAL_8250_NR_UARTS=2
>   CONFIG_SERIAL_8250_RUNTIME_UARTS=2
> -CONFIG_NVRAM=y
>   CONFIG_I2C=y
>   CONFIG_I2C_CHARDEV=y
>   CONFIG_I2C_MPC=y
> @@ -76,4 +73,3 @@ CONFIG_NLS_CODEPAGE_437=y
>   CONFIG_NLS_ISO8859_1=y
>   CONFIG_NLS_UTF8=y
>   CONFIG_CRC_T10DIF=y
> -# CONFIG_ENABLE_MUST_CHECK is not set
>

Daniel Walker (danielwa) March 9, 2021, 9:29 p.m. UTC | #2

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 <prepend><bootloader><append>.

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 Leroy March 24, 2021, 4:59 p.m. UTC | #3

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 ?

> 
> 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

Rob Herring (Arm) March 24, 2021, 5:32 p.m. UTC | #4

On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
<christophe.leroy@csgroup.eu> 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.

Rob

Christophe Leroy March 25, 2021, 12:03 p.m. UTC | #5

Le 24/03/2021 à 18:32, Rob Herring a écrit :
> On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> 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

Rob Herring (Arm) March 25, 2021, 1:45 p.m. UTC | #6

On Thu, Mar 25, 2021 at 6:06 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 24/03/2021 à 18:32, Rob Herring a écrit :
> > On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> 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.

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

Daniel Walker (danielwa) March 25, 2021, 7:56 p.m. UTC | #7

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 <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 ?

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

Daniel Walker (danielwa) March 25, 2021, 7:59 p.m. UTC | #8

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

Rob Herring (Arm) March 25, 2021, 11:29 p.m. UTC | #9

On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker <danielwa@cisco.com> 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

Will Deacon March 29, 2021, 10:07 a.m. UTC | #10

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

Daniel Walker (danielwa) March 30, 2021, 5:32 p.m. UTC | #11

On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote:
> On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker <danielwa@cisco.com> 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

Daniel Walker (danielwa) March 30, 2021, 5:35 p.m. UTC | #12

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

Rob Herring (Arm) March 30, 2021, 8:13 p.m. UTC | #13

On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com> 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

Daniel Walker (danielwa) March 30, 2021, 11:31 p.m. UTC | #14

On Tue, Mar 30, 2021 at 03:13:04PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com> 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

Will Deacon March 31, 2021, 11:52 a.m. UTC | #15

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

Daniel Walker (danielwa) March 31, 2021, 5:14 p.m. UTC | #16

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

Rob Herring (Arm) April 1, 2021, 8:08 p.m. UTC | #17

On Tue, Mar 30, 2021 at 6:31 PM Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com> 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 <danielwa@cisco.com> 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

Daniel Walker (danielwa) April 6, 2021, 4:29 p.m. UTC | #18

On Thu, Apr 01, 2021 at 03:08:04PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 6:31 PM Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com> 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 <danielwa@cisco.com> 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

[v2,3/7] powerpc: convert config files to generic cmdline

Commit Message

Comments

Patch