Re: [RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
On Fri, 2013-08-09 at 16:24 +1000, Stephen Rothwell wrote: We cannot put the unsetting of config options in the Kconfig file, nor the integer or string options. I checked that after this we get the same .config files generated (except for the addition of the new PPC64_DEFCONFIG* config options. Any thoughts? Won't this bypass the dependency mechanism? While the dependencies should already be satisfied currently, nothing would prevent them from being switched off later. Even if you have all the dependencies listed in the select, what if dependencies change later? It seems like it would be better to have a way to apply multiple defconfigs at once, and/or have one defconfig include another. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
Hi Kumar, Thanks for your comments. On Fri, 9 Aug 2013 09:41:54 -0500 Kumar Gala ga...@kernel.crashing.org wrote: On Aug 9, 2013, at 1:24 AM, Stephen Rothwell wrote: We cannot put the unsetting of config options in the Kconfig file, nor the integer or string options. I checked that after this we get the same .config files generated (except for the addition of the new PPC64_DEFCONFIG* config options. Any thoughts? --- arch/powerpc/Kconfig | 2 + arch/powerpc/configs/Kconfig | 295 + arch/powerpc/configs/ppc64_defconfig | 301 +- arch/powerpc/configs/ppc64e_defconfig | 297 + 4 files changed, 302 insertions(+), 593 deletions(-) create mode 100644 arch/powerpc/configs/Kconfig Am I missing something here, isn't this a bit of a maintenance pain if symbol names change? I don't think it is any worse than what we have, and in fact may be better. Currently if someone renames a config option, they usually do nothing about the defconfigs, this way, at least if the option is in configs/Kconfig, they may update it. Also, how much of a benefit is this? There has been some discussion about Anton adding 2 new defconfigs that are very similar to the current defconfigs. This is an attempt to reduce the amount of unnecessary repetition and churn. A similar thing could be done for other sets of similar defconfig files. There was a plan a few years ago to replace the defconfigs with Kconfig fragments and this would be a step along that path. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpAck7jwVjF_.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
We cannot put the unsetting of config options in the Kconfig file, nor the integer or string options. I checked that after this we get the same .config files generated (except for the addition of the new PPC64_DEFCONFIG* config options. Any thoughts? --- arch/powerpc/Kconfig | 2 + arch/powerpc/configs/Kconfig | 295 + arch/powerpc/configs/ppc64_defconfig | 301 +- arch/powerpc/configs/ppc64e_defconfig | 297 + 4 files changed, 302 insertions(+), 593 deletions(-) create mode 100644 arch/powerpc/configs/Kconfig diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 3bf72cd..a95649f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -1020,3 +1020,5 @@ config PPC_LIB_RHEAP bool source arch/powerpc/kvm/Kconfig + +source arch/powerpc/configs/Kconfig diff --git a/arch/powerpc/configs/Kconfig b/arch/powerpc/configs/Kconfig new file mode 100644 index 000..05b693c --- /dev/null +++ b/arch/powerpc/configs/Kconfig @@ -0,0 +1,295 @@ +config PPC64_DEFCONFIG_COMMON + bool Common settings for ppc64 defconfigs + select ACENIC_OMIT_TIGON_I + select ATA + select BLK_DEV_AMD74XX + select BLK_DEV_DM + select BLK_DEV_FD + select BLK_DEV_GENERIC + select BLK_DEV_IDECD + select BLK_DEV_INITRD + select BLK_DEV_IO_TRACE + select BLK_DEV_LOOP + select BLK_DEV_MD + select BLK_DEV_RAM + select BLK_DEV_SD + select BLK_DEV_SR + select BLK_DEV_SR_VENDOR + select CGROUPS + select CHR_DEV_SG + select CHR_DEV_ST + select CIFS_POSIX + select CIFS_XATTR + select CODE_PATCHING_SELFTEST + select CPUSETS + select CPU_FREQ + select CPU_FREQ_GOV_POWERSAVE + select CPU_FREQ_GOV_USERSPACE + select CRC_T10DIF + select CRYPTO_HMAC + select DEBUG_KERNEL + select DEBUG_MUTEXES + select DEBUG_STACKOVERFLOW + select DEBUG_STACK_USAGE + select DEVTMPFS + select DEVTMPFS_MOUNT + select E100 + select E1000 + select EDAC + select EDAC_MM_EDAC + select EXT2_FS + select EXT2_FS_POSIX_ACL + select EXT2_FS_SECURITY + select EXT2_FS_XATTR + select EXT2_FS_XIP + select EXT3_FS + select EXT3_FS_POSIX_ACL + select EXT3_FS_SECURITY + select EXT4_FS + select EXT4_FS_POSIX_ACL + select EXT4_FS_SECURITY + select FB + select FB_IBM_GXT4500 + select FB_MATROX + select FB_MATROX_G + select FB_MATROX_MILLENIUM + select FB_MATROX_MYSTIQUE + select FB_OF + select FB_RADEON + select FIRMWARE_EDID + select FRAMEBUFFER_CONSOLE + select FTR_FIXUP_SELFTEST + select HID_GYRATION + select HID_PANTHERLORD + select HID_PETALYNX + select HID_SAMSUNG + select HID_SUNPLUS + select HIGH_RES_TIMERS + select HOTPLUG_PCI + select I2C_AMD8111 + select I2C_CHARDEV + select IDE + select IKCONFIG + select IKCONFIG_PROC + select INET + select INPUT_MISC + select IP_MULTICAST + select IP_PNP + select IP_PNP_BOOTP + select IP_PNP_DHCP + select IRQ_ALL_CPUS + select ISO9660_FS + select JFS_POSIX_ACL + select JFS_SECURITY + select LATENCYTOP + select LCD_CLASS_DEVICE + select LOGO + select MAGIC_SYSRQ + select MARVELL_PHY + select MD + select MD_LINEAR + select MD_RAID0 + select MD_RAID1 + select MODULES + select MODULE_SRCVERSION_ALL + select MODULE_UNLOAD + select MODVERSIONS + select MSDOS_FS + select MSI_BITMAP_SELFTEST + select NETCONSOLE + select NETFILTER + select NETPOLL_TRAP + select NET_IPIP + select NFSD_V3_ACL + select NFSD_V4 + select NFS_FS + select NFS_V3_ACL + select NFS_V4 + select NF_CONNTRACK_EVENTS + select NLS_ASCII + select NLS_CODEPAGE_437 + select NLS_ISO8859_1 + select NLS_UTF8 + select NO_HZ + select OPROFILE + select PACKET + select PARTITION_ADVANCED + select PCCARD + select PCNET32 + select POSIX_MQUEUE + select PPC64 + select PROC_DEVICETREE + select PROC_KCORE + select PROFILING + select RAW_DRIVER + select REISERFS_FS + select REISERFS_FS_POSIX_ACL + select REISERFS_FS_SECURITY + select REISERFS_FS_XATTR + select ROOT_NFS + select RTC_CLASS + select RTC_DRV_DS1307 + select SATA_SIL24 + select SATA_SVW + select SCHED_TRACER + select SCSI_CONSTANTS + select SCSI_FC_ATTRS + select SCSI_IPR + select SCSI_MULTI_LUN + select SCSI_SYM53C8XX_2 + select SERIAL_8250 + select
Re: [RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
Stephen Rothwell s...@canb.auug.org.au wrote: We cannot put the unsetting of config options in the Kconfig file, nor the integer or string options. I checked that after this we get the same .config files generated (except for the addition of the new PPC64_DEFCONFIG* config options. Any thoughts? +1 Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
On Aug 9, 2013, at 1:24 AM, Stephen Rothwell wrote: We cannot put the unsetting of config options in the Kconfig file, nor the integer or string options. I checked that after this we get the same .config files generated (except for the addition of the new PPC64_DEFCONFIG* config options. Any thoughts? --- arch/powerpc/Kconfig | 2 + arch/powerpc/configs/Kconfig | 295 + arch/powerpc/configs/ppc64_defconfig | 301 +- arch/powerpc/configs/ppc64e_defconfig | 297 + 4 files changed, 302 insertions(+), 593 deletions(-) create mode 100644 arch/powerpc/configs/Kconfig Am I missing something here, isn't this a bit of a maintenance pain if symbol names change? Also, how much of a benefit is this? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
