* [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-11 18:52 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-11 18:52 UTC (permalink / raw)
To: linux-kernel
Cc: rmk, tony.luck, linux-ia64, matthew, grundler, parisc-linux,
paulus, linuxppc-dev, lethal, kkojima, linux-sh
defconfig's shouldn't set CONFIG_BROKEN=y.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/arm/configs/bast_defconfig | 3 +--
arch/arm/configs/collie_defconfig | 3 +--
arch/arm/configs/s3c2410_defconfig | 3 +--
arch/ia64/configs/sim_defconfig | 3 +--
arch/ia64/configs/zx1_defconfig | 3 +--
arch/m32r/mappi/defconfig.smp | 3 +--
arch/m32r/mappi/defconfig.up | 3 +--
arch/m32r/mappi3/defconfig.smp | 3 +--
arch/parisc/configs/712_defconfig | 3 +--
arch/parisc/configs/a500_defconfig | 3 +--
arch/parisc/configs/c3000_defconfig | 3 +--
arch/ppc/configs/mpc86x_ads_defconfig | 3 +--
arch/ppc/configs/mpc885ads_defconfig | 3 +--
arch/ppc/configs/rpxcllf_defconfig | 3 +--
arch/ppc/configs/rpxlite_defconfig | 3 +--
arch/sh/configs/hp680_defconfig | 3 +--
arch/sh/configs/sh03_defconfig | 3 +--
arch/sh/configs/systemh_defconfig | 3 +--
18 files changed, 18 insertions(+), 36 deletions(-)
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig.old 2005-12-11 19:37:15.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig 2005-12-11 19:37:37.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig.old 2005-12-11 19:37:44.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig 2005-12-11 19:37:52.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig.old 2005-12-11 19:38:01.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig 2005-12-11 19:38:08.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig.old 2005-12-11 19:38:17.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig 2005-12-11 19:38:38.000000000 +0100
@@ -6,9 +6,8 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
+CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
-CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig.old 2005-12-11 19:38:52.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig 2005-12-11 19:38:59.000000000 +0100
@@ -8,8 +8,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp.old 2005-12-11 19:39:08.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp 2005-12-11 19:39:15.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up.old 2005-12-11 19:39:25.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up 2005-12-11 19:39:32.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp.old 2005-12-11 19:39:41.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp 2005-12-11 19:39:48.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig.old 2005-12-11 19:40:00.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig 2005-12-11 19:40:08.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig.old 2005-12-11 19:40:32.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig 2005-12-11 19:40:38.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig.old 2005-12-11 19:40:50.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig 2005-12-11 19:40:57.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig.old 2005-12-11 19:41:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig 2005-12-11 19:42:01.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig.old 2005-12-11 19:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig 2005-12-11 19:42:30.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig.old 2005-12-11 19:42:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig 2005-12-11 19:42:48.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig.old 2005-12-11 19:43:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig 2005-12-11 19:43:27.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig.old 2005-12-11 19:43:36.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig 2005-12-11 19:43:43.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig.old 2005-12-11 19:43:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig 2005-12-11 19:44:02.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig.old 2005-12-11 19:44:19.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig 2005-12-11 19:44:40.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-11 18:52 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-11 18:52 UTC (permalink / raw)
To: linux-kernel
Cc: linux-sh, tony.luck, linux-ia64, grundler, matthew, linuxppc-dev,
lethal, kkojima, rmk, parisc-linux
defconfig's shouldn't set CONFIG_BROKEN=y.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/arm/configs/bast_defconfig | 3 +--
arch/arm/configs/collie_defconfig | 3 +--
arch/arm/configs/s3c2410_defconfig | 3 +--
arch/ia64/configs/sim_defconfig | 3 +--
arch/ia64/configs/zx1_defconfig | 3 +--
arch/m32r/mappi/defconfig.smp | 3 +--
arch/m32r/mappi/defconfig.up | 3 +--
arch/m32r/mappi3/defconfig.smp | 3 +--
arch/parisc/configs/712_defconfig | 3 +--
arch/parisc/configs/a500_defconfig | 3 +--
arch/parisc/configs/c3000_defconfig | 3 +--
arch/ppc/configs/mpc86x_ads_defconfig | 3 +--
arch/ppc/configs/mpc885ads_defconfig | 3 +--
arch/ppc/configs/rpxcllf_defconfig | 3 +--
arch/ppc/configs/rpxlite_defconfig | 3 +--
arch/sh/configs/hp680_defconfig | 3 +--
arch/sh/configs/sh03_defconfig | 3 +--
arch/sh/configs/systemh_defconfig | 3 +--
18 files changed, 18 insertions(+), 36 deletions(-)
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig.old 2005-12-11 19:37:15.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig 2005-12-11 19:37:37.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig.old 2005-12-11 19:37:44.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig 2005-12-11 19:37:52.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig.old 2005-12-11 19:38:01.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig 2005-12-11 19:38:08.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig.old 2005-12-11 19:38:17.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig 2005-12-11 19:38:38.000000000 +0100
@@ -6,9 +6,8 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
+CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
-CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig.old 2005-12-11 19:38:52.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig 2005-12-11 19:38:59.000000000 +0100
@@ -8,8 +8,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp.old 2005-12-11 19:39:08.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp 2005-12-11 19:39:15.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up.old 2005-12-11 19:39:25.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up 2005-12-11 19:39:32.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp.old 2005-12-11 19:39:41.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp 2005-12-11 19:39:48.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig.old 2005-12-11 19:40:00.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig 2005-12-11 19:40:08.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig.old 2005-12-11 19:40:32.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig 2005-12-11 19:40:38.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig.old 2005-12-11 19:40:50.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig 2005-12-11 19:40:57.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig.old 2005-12-11 19:41:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig 2005-12-11 19:42:01.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig.old 2005-12-11 19:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig 2005-12-11 19:42:30.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig.old 2005-12-11 19:42:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig 2005-12-11 19:42:48.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig.old 2005-12-11 19:43:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig 2005-12-11 19:43:27.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig.old 2005-12-11 19:43:36.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig 2005-12-11 19:43:43.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig.old 2005-12-11 19:43:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig 2005-12-11 19:44:02.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig.old 2005-12-11 19:44:19.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig 2005-12-11 19:44:40.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-11 18:52 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-11 18:52 UTC (permalink / raw)
To: linux-kernel
Cc: rmk, tony.luck, linux-ia64, matthew, grundler, parisc-linux,
paulus, linuxppc-dev, lethal, kkojima, linux-sh
defconfig's shouldn't set CONFIG_BROKEN=y.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/arm/configs/bast_defconfig | 3 +--
arch/arm/configs/collie_defconfig | 3 +--
arch/arm/configs/s3c2410_defconfig | 3 +--
arch/ia64/configs/sim_defconfig | 3 +--
arch/ia64/configs/zx1_defconfig | 3 +--
arch/m32r/mappi/defconfig.smp | 3 +--
arch/m32r/mappi/defconfig.up | 3 +--
arch/m32r/mappi3/defconfig.smp | 3 +--
arch/parisc/configs/712_defconfig | 3 +--
arch/parisc/configs/a500_defconfig | 3 +--
arch/parisc/configs/c3000_defconfig | 3 +--
arch/ppc/configs/mpc86x_ads_defconfig | 3 +--
arch/ppc/configs/mpc885ads_defconfig | 3 +--
arch/ppc/configs/rpxcllf_defconfig | 3 +--
arch/ppc/configs/rpxlite_defconfig | 3 +--
arch/sh/configs/hp680_defconfig | 3 +--
arch/sh/configs/sh03_defconfig | 3 +--
arch/sh/configs/systemh_defconfig | 3 +--
18 files changed, 18 insertions(+), 36 deletions(-)
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig.old 2005-12-11 19:37:15.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig 2005-12-11 19:37:37.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig.old 2005-12-11 19:37:44.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig 2005-12-11 19:37:52.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig.old 2005-12-11 19:38:01.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig 2005-12-11 19:38:08.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig.old 2005-12-11 19:38:17.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig 2005-12-11 19:38:38.000000000 +0100
@@ -6,9 +6,8 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
+CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
-CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig.old 2005-12-11 19:38:52.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig 2005-12-11 19:38:59.000000000 +0100
@@ -8,8 +8,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp.old 2005-12-11 19:39:08.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp 2005-12-11 19:39:15.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up.old 2005-12-11 19:39:25.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up 2005-12-11 19:39:32.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp.old 2005-12-11 19:39:41.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp 2005-12-11 19:39:48.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig.old 2005-12-11 19:40:00.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig 2005-12-11 19:40:08.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig.old 2005-12-11 19:40:32.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig 2005-12-11 19:40:38.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig.old 2005-12-11 19:40:50.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig 2005-12-11 19:40:57.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig.old 2005-12-11 19:41:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig 2005-12-11 19:42:01.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig.old 2005-12-11 19:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig 2005-12-11 19:42:30.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT2
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig.old 2005-12-11 19:42:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig 2005-12-11 19:42:48.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig.old 2005-12-11 19:43:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig 2005-12-11 19:43:27.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig.old 2005-12-11 19:43:36.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig 2005-12-11 19:43:43.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig.old 2005-12-11 19:43:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig 2005-12-11 19:44:02.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig.old 2005-12-11 19:44:19.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig 2005-12-11 19:44:40.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-11 18:52 ` Adrian Bunk
@ 2005-12-11 19:21 ` Russell King
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-11 19:21 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, linux-sh
On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> defconfig's shouldn't set CONFIG_BROKEN=y.
NACK. This changes other configuration options in addition, for example
in collie_defconfig:
-CONFIG_MTD_OBSOLETE_CHIPS=y
-# CONFIG_MTD_AMDSTD is not set
-CONFIG_MTD_SHARP=y
-# CONFIG_MTD_JEDEC is not set
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-11 19:21 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-11 19:21 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-sh, tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, kkojima, parisc-linux
On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> defconfig's shouldn't set CONFIG_BROKEN=y.
NACK. This changes other configuration options in addition, for example
in collie_defconfig:
-CONFIG_MTD_OBSOLETE_CHIPS=y
-# CONFIG_MTD_AMDSTD is not set
-CONFIG_MTD_SHARP=y
-# CONFIG_MTD_JEDEC is not set
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-11 19:21 ` Russell King
@ 2005-12-11 19:31 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-11 19:31 UTC (permalink / raw)
To: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2
Cc: linux-mtd
On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > defconfig's shouldn't set CONFIG_BROKEN=y.
>
> NACK. This changes other configuration options in addition, for example
> in collie_defconfig:
>
> -CONFIG_MTD_OBSOLETE_CHIPS=y
> -# CONFIG_MTD_AMDSTD is not set
> -CONFIG_MTD_SHARP=y
> -# CONFIG_MTD_JEDEC is not set
That's not a problem introduced by my patch.
Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in which
case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything), or the
dependency on BROKEN is not correct and should be corrected.
David, can you comment on this issue?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-11 19:31 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-11 19:31 UTC (permalink / raw)
To: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2
Cc: linux-mtd
On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > defconfig's shouldn't set CONFIG_BROKEN=y.
>
> NACK. This changes other configuration options in addition, for example
> in collie_defconfig:
>
> -CONFIG_MTD_OBSOLETE_CHIPS=y
> -# CONFIG_MTD_AMDSTD is not set
> -CONFIG_MTD_SHARP=y
> -# CONFIG_MTD_JEDEC is not set
That's not a problem introduced by my patch.
Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in which
case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything), or the
dependency on BROKEN is not correct and should be corrected.
David, can you comment on this issue?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-11 19:31 ` Adrian Bunk
@ 2005-12-11 19:44 ` Russell King
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-11 19:44 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
On Sun, Dec 11, 2005 at 08:31:18PM +0100, Adrian Bunk wrote:
> On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> > On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > > defconfig's shouldn't set CONFIG_BROKEN=y.
> >
> > NACK. This changes other configuration options in addition, for example
> > in collie_defconfig:
> >
> > -CONFIG_MTD_OBSOLETE_CHIPS=y
> > -# CONFIG_MTD_AMDSTD is not set
> > -CONFIG_MTD_SHARP=y
> > -# CONFIG_MTD_JEDEC is not set
>
> That's not a problem introduced by my patch.
It's a problem introduced by your patch because the resulting defconfig
file becomes _wrong_ by your change, and other changes in the defconfig
are thereby hidden.
If you change any options in a defconfig file, and they're obviously not
leaf options, you should check what impact they have on other options by
running it through an "oldconfig" cycle. That's what I just did with
this script:
#!/bin/sh -e
alias amake='make CROSS_COMPILE=arm-linux- ARCH=arm'
amake $1 O=../build/t >/dev/null 2>&1
mv ../build/t/.config ../build/t/.config.orig
sed '/CONFIG_BROKEN/d;s,^# CONFIG_CLEAN_COMPILE is not set,CONFIG_CLEAN_COMPILE=y,' < ../build/t/.config.orig > ../build/t/.config
amake oldconfig O=../build/t >/dev/null 2>&1
diff -u ../build/t/.config.orig ../build/t/.config
Hence I discovered that disabling CONFIG_BROKEN removes the above
options for the collie case.
BTW, it might be worth using something like the above script for all
the changes to the defconfig files in your patch so that it correctly
updates these files. It will also mean that any review of it is more
meaningful because we can see the full extent of your changes.
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in which
> case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything), or the
> dependency on BROKEN is not correct and should be corrected.
That's something which collie folk need to comment on. However, what
I can say is that the collie_defconfig builds successfully today:
http://armlinux.simtec.co.uk/kautobuild/2.6.15-rc5-git1/collie_defconfig/zimage.log
so it's quite possible that the Kconfig is out of sync with reality.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-11 19:44 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-11 19:44 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linux-mtd, linuxppc-dev, lethal, dwmw2, kkojima, parisc-linux
On Sun, Dec 11, 2005 at 08:31:18PM +0100, Adrian Bunk wrote:
> On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> > On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > > defconfig's shouldn't set CONFIG_BROKEN=y.
> >
> > NACK. This changes other configuration options in addition, for example
> > in collie_defconfig:
> >
> > -CONFIG_MTD_OBSOLETE_CHIPS=y
> > -# CONFIG_MTD_AMDSTD is not set
> > -CONFIG_MTD_SHARP=y
> > -# CONFIG_MTD_JEDEC is not set
>
> That's not a problem introduced by my patch.
It's a problem introduced by your patch because the resulting defconfig
file becomes _wrong_ by your change, and other changes in the defconfig
are thereby hidden.
If you change any options in a defconfig file, and they're obviously not
leaf options, you should check what impact they have on other options by
running it through an "oldconfig" cycle. That's what I just did with
this script:
#!/bin/sh -e
alias amake='make CROSS_COMPILE=arm-linux- ARCH=arm'
amake $1 O=../build/t >/dev/null 2>&1
mv ../build/t/.config ../build/t/.config.orig
sed '/CONFIG_BROKEN/d;s,^# CONFIG_CLEAN_COMPILE is not set,CONFIG_CLEAN_COMPILE=y,' < ../build/t/.config.orig > ../build/t/.config
amake oldconfig O=../build/t >/dev/null 2>&1
diff -u ../build/t/.config.orig ../build/t/.config
Hence I discovered that disabling CONFIG_BROKEN removes the above
options for the collie case.
BTW, it might be worth using something like the above script for all
the changes to the defconfig files in your patch so that it correctly
updates these files. It will also mean that any review of it is more
meaningful because we can see the full extent of your changes.
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in which
> case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything), or the
> dependency on BROKEN is not correct and should be corrected.
That's something which collie folk need to comment on. However, what
I can say is that the collie_defconfig builds successfully today:
http://armlinux.simtec.co.uk/kautobuild/2.6.15-rc5-git1/collie_defconfig/zimage.log
so it's quite possible that the Kconfig is out of sync with reality.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-11 19:31 ` Adrian Bunk
(?)
@ 2005-12-12 9:38 ` David Woodhouse
-1 siblings, 0 replies; 70+ messages in thread
From: David Woodhouse @ 2005-12-12 9:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, linux-mtd
On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> or the dependency on BROKEN is not correct and should be corrected.
>
> David, can you comment on this issue?
I don't see any justification for MTD_OBSOLETE_CHIPS depending on
BROKEN. That option covers a few of the obsolete chip drivers which
people shouldn't be using any more -- and I'm perfectly willing to
believe that one or two of those don't work any more, but if that's the
case then those individual drivers ought to be marked BROKEN (or just
removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
I'd like to see the collie_defconfig updated to use the appropriate CFI
driver back end.
--
dwmw2
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-12 9:38 ` David Woodhouse
0 siblings, 0 replies; 70+ messages in thread
From: David Woodhouse @ 2005-12-12 9:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linux-mtd, linuxppc-dev, lethal, kkojima, parisc-linux
On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> or the dependency on BROKEN is not correct and should be corrected.
>
> David, can you comment on this issue?
I don't see any justification for MTD_OBSOLETE_CHIPS depending on
BROKEN. That option covers a few of the obsolete chip drivers which
people shouldn't be using any more -- and I'm perfectly willing to
believe that one or two of those don't work any more, but if that's the
case then those individual drivers ought to be marked BROKEN (or just
removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
I'd like to see the collie_defconfig updated to use the appropriate CFI
driver back end.
--
dwmw2
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-12 9:38 ` David Woodhouse
0 siblings, 0 replies; 70+ messages in thread
From: David Woodhouse @ 2005-12-12 9:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, linux-mtd
On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> or the dependency on BROKEN is not correct and should be corrected.
>
> David, can you comment on this issue?
I don't see any justification for MTD_OBSOLETE_CHIPS depending on
BROKEN. That option covers a few of the obsolete chip drivers which
people shouldn't be using any more -- and I'm perfectly willing to
believe that one or two of those don't work any more, but if that's the
case then those individual drivers ought to be marked BROKEN (or just
removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
I'd like to see the collie_defconfig updated to use the appropriate CFI
driver back end.
--
dwmw2
^ permalink raw reply [flat|nested] 70+ messages in thread
* [RFC: 2.6 patch] no longer mark MTD_OBSOLETE_CHIPS as BROKEN and remove broken MTD_OBSOLETE_CHIPS drivers
2005-12-12 9:38 ` David Woodhouse
@ 2005-12-13 0:06 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 0:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
On Mon, Dec 12, 2005 at 10:38:15AM +0100, David Woodhouse wrote:
> On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> > Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> > which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> > or the dependency on BROKEN is not correct and should be corrected.
> >
> > David, can you comment on this issue?
>
> I don't see any justification for MTD_OBSOLETE_CHIPS depending on
> BROKEN. That option covers a few of the obsolete chip drivers which
> people shouldn't be using any more -- and I'm perfectly willing to
> believe that one or two of those don't work any more, but if that's the
> case then those individual drivers ought to be marked BROKEN (or just
> removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
>...
Two of them don't even compile any more.
The patch below removes them and all code depending on them and makes
the remaining one (MTD_SHARP) compilable again.
> dwmw2
cu
Adrian
<-- snip -->
MTD_OBSOLETE_CHIPS shouldn't be marked as BROKEN.
This patch brings the MTD_SHARP driver back into life and removes the
non-compiling MTD_AMDSTD and MTD_JEDEC with everything depending on
them.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
<-- snip -->
Due to it's size, the patch is attached gzip'ed.
arch/cris/arch-v10/drivers/Kconfig | 1
arch/cris/arch-v10/drivers/axisflashmap.c | 3
arch/cris/arch-v32/drivers/Kconfig | 1
arch/cris/arch-v32/drivers/axisflashmap.c | 3
drivers/mtd/chips/Kconfig | 22
drivers/mtd/chips/Makefile | 2
drivers/mtd/chips/amd_flash.c | 1403 ----------------------
drivers/mtd/chips/jedec.c | 935 --------------
drivers/mtd/maps/Kconfig | 18
drivers/mtd/maps/Makefile | 2
drivers/mtd/maps/octagon-5066.c | 248 ---
drivers/mtd/maps/vmax301.c | 198 ---
include/linux/mtd/jedec.h | 66 -
13 files changed, 1 insertion(+), 2901 deletions(-)
[-- Attachment #2: patch-MTD_OBSOLETE_CHIPS.gz --]
[-- Type: application/octet-stream, Size: 19885 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* [RFC: 2.6 patch] no longer mark MTD_OBSOLETE_CHIPS as BROKEN and remove broken MTD_OBSOLETE_CHIPS drivers
@ 2005-12-13 0:06 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 0:06 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
On Mon, Dec 12, 2005 at 10:38:15AM +0100, David Woodhouse wrote:
> On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> > Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> > which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> > or the dependency on BROKEN is not correct and should be corrected.
> >
> > David, can you comment on this issue?
>
> I don't see any justification for MTD_OBSOLETE_CHIPS depending on
> BROKEN. That option covers a few of the obsolete chip drivers which
> people shouldn't be using any more -- and I'm perfectly willing to
> believe that one or two of those don't work any more, but if that's the
> case then those individual drivers ought to be marked BROKEN (or just
> removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
>...
Two of them don't even compile any more.
The patch below removes them and all code depending on them and makes
the remaining one (MTD_SHARP) compilable again.
> dwmw2
cu
Adrian
<-- snip -->
MTD_OBSOLETE_CHIPS shouldn't be marked as BROKEN.
This patch brings the MTD_SHARP driver back into life and removes the
non-compiling MTD_AMDSTD and MTD_JEDEC with everything depending on
them.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
<-- snip -->
Due to it's size, the patch is attached gzip'ed.
arch/cris/arch-v10/drivers/Kconfig | 1
arch/cris/arch-v10/drivers/axisflashmap.c | 3
arch/cris/arch-v32/drivers/Kconfig | 1
arch/cris/arch-v32/drivers/axisflashmap.c | 3
drivers/mtd/chips/Kconfig | 22
drivers/mtd/chips/Makefile | 2
drivers/mtd/chips/amd_flash.c | 1403 ----------------------
drivers/mtd/chips/jedec.c | 935 --------------
drivers/mtd/maps/Kconfig | 18
drivers/mtd/maps/Makefile | 2
drivers/mtd/maps/octagon-5066.c | 248 ---
drivers/mtd/maps/vmax301.c | 198 ---
include/linux/mtd/jedec.h | 66 -
13 files changed, 1 insertion(+), 2901 deletions(-)
[-- Attachment #2: patch-MTD_OBSOLETE_CHIPS.gz --]
[-- Type: application/octet-stream, Size: 19885 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-11 19:44 ` Russell King
(?)
@ 2005-12-13 0:10 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 0:10 UTC (permalink / raw)
To: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
On Sun, Dec 11, 2005 at 07:44:37PM +0000, Russell King wrote:
> On Sun, Dec 11, 2005 at 08:31:18PM +0100, Adrian Bunk wrote:
> > On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> > > On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > > > defconfig's shouldn't set CONFIG_BROKEN=y.
> > >
> > > NACK. This changes other configuration options in addition, for example
> > > in collie_defconfig:
> > >
> > > -CONFIG_MTD_OBSOLETE_CHIPS=y
> > > -# CONFIG_MTD_AMDSTD is not set
> > > -CONFIG_MTD_SHARP=y
> > > -# CONFIG_MTD_JEDEC is not set
> >
> > That's not a problem introduced by my patch.
>
> It's a problem introduced by your patch because the resulting defconfig
> file becomes _wrong_ by your change, and other changes in the defconfig
> are thereby hidden.
>...
No, CONFIG_BROKEN=y in a defconfig file is a bug.
Either the defconfig doesn't use BROKEN code in which case it's simply
wrong, or it's a wrong workaround (as in the CONFIG_MTD_SHARP case) for
a wrong BROKEN dependency.
And it's a dangerous workaround:
Consider e.g. that "both marked as obsolete and BROKEN" are the best
candidates for "remove obsolete code" cleanups - and there goes your
driver to /dev/null ...
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 0:10 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 0:10 UTC (permalink / raw)
To: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
On Sun, Dec 11, 2005 at 07:44:37PM +0000, Russell King wrote:
> On Sun, Dec 11, 2005 at 08:31:18PM +0100, Adrian Bunk wrote:
> > On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> > > On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > > > defconfig's shouldn't set CONFIG_BROKEN=y.
> > >
> > > NACK. This changes other configuration options in addition, for example
> > > in collie_defconfig:
> > >
> > > -CONFIG_MTD_OBSOLETE_CHIPS=y
> > > -# CONFIG_MTD_AMDSTD is not set
> > > -CONFIG_MTD_SHARP=y
> > > -# CONFIG_MTD_JEDEC is not set
> >
> > That's not a problem introduced by my patch.
>
> It's a problem introduced by your patch because the resulting defconfig
> file becomes _wrong_ by your change, and other changes in the defconfig
> are thereby hidden.
>...
No, CONFIG_BROKEN=y in a defconfig file is a bug.
Either the defconfig doesn't use BROKEN code in which case it's simply
wrong, or it's a wrong workaround (as in the CONFIG_MTD_SHARP case) for
a wrong BROKEN dependency.
And it's a dangerous workaround:
Consider e.g. that "both marked as obsolete and BROKEN" are the best
candidates for "remove obsolete code" cleanups - and there goes your
driver to /dev/null ...
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 0:10 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 0:10 UTC (permalink / raw)
To: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
On Sun, Dec 11, 2005 at 07:44:37PM +0000, Russell King wrote:
> On Sun, Dec 11, 2005 at 08:31:18PM +0100, Adrian Bunk wrote:
> > On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> > > On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > > > defconfig's shouldn't set CONFIG_BROKEN=y.
> > >
> > > NACK. This changes other configuration options in addition, for example
> > > in collie_defconfig:
> > >
> > > -CONFIG_MTD_OBSOLETE_CHIPS=y
> > > -# CONFIG_MTD_AMDSTD is not set
> > > -CONFIG_MTD_SHARP=y
> > > -# CONFIG_MTD_JEDEC is not set
> >
> > That's not a problem introduced by my patch.
>
> It's a problem introduced by your patch because the resulting defconfig
> file becomes _wrong_ by your change, and other changes in the defconfig
> are thereby hidden.
>...
No, CONFIG_BROKEN=y in a defconfig file is a bug.
Either the defconfig doesn't use BROKEN code in which case it's simply
wrong, or it's a wrong workaround (as in the CONFIG_MTD_SHARP case) for
a wrong BROKEN dependency.
And it's a dangerous workaround:
Consider e.g. that "both marked as obsolete and BROKEN" are the best
candidates for "remove obsolete code" cleanups - and there goes your
driver to /dev/null ...
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-13 0:10 ` Adrian Bunk
(?)
@ 2005-12-13 13:34 ` Simon Richter
-1 siblings, 0 replies; 70+ messages in thread
From: Simon Richter @ 2005-12-13 13:34 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Hi,
Adrian Bunk wrote:
>>It's a problem introduced by your patch because the resulting defconfig
>>file becomes _wrong_ by your change, and other changes in the defconfig
>>are thereby hidden.
>>...
> No, CONFIG_BROKEN=y in a defconfig file is a bug.
Indeed, but that's not the point. A defconfig file should be the result
of running one of the various configuration targets; yours are
hand-patched. If you run the defconfig target, it will copy the config
file and run oldconfig, thus resulting in a different configuration file
(because options may now be gone and hence disabled) than what was in
the defconfig, and thus people may come to the wrong conclusion that if
a driver is enabled in a defconfig file, it will be built.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 13:34 ` Simon Richter
0 siblings, 0 replies; 70+ messages in thread
From: Simon Richter @ 2005-12-13 13:34 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Hi,
Adrian Bunk wrote:
>>It's a problem introduced by your patch because the resulting defconfig
>>file becomes _wrong_ by your change, and other changes in the defconfig
>>are thereby hidden.
>>...
> No, CONFIG_BROKEN=y in a defconfig file is a bug.
Indeed, but that's not the point. A defconfig file should be the result
of running one of the various configuration targets; yours are
hand-patched. If you run the defconfig target, it will copy the config
file and run oldconfig, thus resulting in a different configuration file
(because options may now be gone and hence disabled) than what was in
the defconfig, and thus people may come to the wrong conclusion that if
a driver is enabled in a defconfig file, it will be built.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 13:34 ` Simon Richter
0 siblings, 0 replies; 70+ messages in thread
From: Simon Richter @ 2005-12-13 13:34 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Hi,
Adrian Bunk wrote:
>>It's a problem introduced by your patch because the resulting defconfig
>>file becomes _wrong_ by your change, and other changes in the defconfig
>>are thereby hidden.
>>...
> No, CONFIG_BROKEN=y in a defconfig file is a bug.
Indeed, but that's not the point. A defconfig file should be the result
of running one of the various configuration targets; yours are
hand-patched. If you run the defconfig target, it will copy the config
file and run oldconfig, thus resulting in a different configuration file
(because options may now be gone and hence disabled) than what was in
the defconfig, and thus people may come to the wrong conclusion that if
a driver is enabled in a defconfig file, it will be built.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-13 13:34 ` Simon Richter
(?)
(?)
@ 2005-12-13 14:00 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 14:00 UTC (permalink / raw)
To: Simon Richter
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
On Tue, Dec 13, 2005 at 02:34:04PM +0100, Simon Richter wrote:
> Hi,
Hi Simon,
> Adrian Bunk wrote:
>
> >>It's a problem introduced by your patch because the resulting defconfig
> >>file becomes _wrong_ by your change, and other changes in the defconfig
> >>are thereby hidden.
> >>...
>
> >No, CONFIG_BROKEN=y in a defconfig file is a bug.
>
> Indeed, but that's not the point. A defconfig file should be the result
> of running one of the various configuration targets; yours are
> hand-patched. If you run the defconfig target, it will copy the config
> file and run oldconfig, thus resulting in a different configuration file
> (because options may now be gone and hence disabled) than what was in
> the defconfig, and thus people may come to the wrong conclusion that if
> a driver is enabled in a defconfig file, it will be built.
defconfig files are virtually never a configuration for the kernel they
are shipped with since they aren't updated every time some configuration
option is changed.
Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
in this defconfig gets for some reason marked as broken in the Kconfig
file - this will give exactly the same result as the one you describe.
> Simon
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 14:00 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 14:00 UTC (permalink / raw)
To: Simon Richter
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
On Tue, Dec 13, 2005 at 02:34:04PM +0100, Simon Richter wrote:
> Hi,
Hi Simon,
> Adrian Bunk wrote:
>
> >>It's a problem introduced by your patch because the resulting defconfig
> >>file becomes _wrong_ by your change, and other changes in the defconfig
> >>are thereby hidden.
> >>...
>
> >No, CONFIG_BROKEN=y in a defconfig file is a bug.
>
> Indeed, but that's not the point. A defconfig file should be the result
> of running one of the various configuration targets; yours are
> hand-patched. If you run the defconfig target, it will copy the config
> file and run oldconfig, thus resulting in a different configuration file
> (because options may now be gone and hence disabled) than what was in
> the defconfig, and thus people may come to the wrong conclusion that if
> a driver is enabled in a defconfig file, it will be built.
defconfig files are virtually never a configuration for the kernel they
are shipped with since they aren't updated every time some configuration
option is changed.
Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
in this defconfig gets for some reason marked as broken in the Kconfig
file - this will give exactly the same result as the one you describe.
> Simon
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 14:00 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 14:00 UTC (permalink / raw)
To: Simon Richter
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, paulus, linux-mtd, dwmw2, kkojima,
parisc-linux
On Tue, Dec 13, 2005 at 02:34:04PM +0100, Simon Richter wrote:
> Hi,
Hi Simon,
> Adrian Bunk wrote:
>
> >>It's a problem introduced by your patch because the resulting defconfig
> >>file becomes _wrong_ by your change, and other changes in the defconfig
> >>are thereby hidden.
> >>...
>
> >No, CONFIG_BROKEN=y in a defconfig file is a bug.
>
> Indeed, but that's not the point. A defconfig file should be the result
> of running one of the various configuration targets; yours are
> hand-patched. If you run the defconfig target, it will copy the config
> file and run oldconfig, thus resulting in a different configuration file
> (because options may now be gone and hence disabled) than what was in
> the defconfig, and thus people may come to the wrong conclusion that if
> a driver is enabled in a defconfig file, it will be built.
defconfig files are virtually never a configuration for the kernel they
are shipped with since they aren't updated every time some configuration
option is changed.
Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
in this defconfig gets for some reason marked as broken in the Kconfig
file - this will give exactly the same result as the one you describe.
> Simon
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 14:00 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 14:00 UTC (permalink / raw)
To: Simon Richter
Cc: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2,
linux-mtd
On Tue, Dec 13, 2005 at 02:34:04PM +0100, Simon Richter wrote:
> Hi,
Hi Simon,
> Adrian Bunk wrote:
>
> >>It's a problem introduced by your patch because the resulting defconfig
> >>file becomes _wrong_ by your change, and other changes in the defconfig
> >>are thereby hidden.
> >>...
>
> >No, CONFIG_BROKEN=y in a defconfig file is a bug.
>
> Indeed, but that's not the point. A defconfig file should be the result
> of running one of the various configuration targets; yours are
> hand-patched. If you run the defconfig target, it will copy the config
> file and run oldconfig, thus resulting in a different configuration file
> (because options may now be gone and hence disabled) than what was in
> the defconfig, and thus people may come to the wrong conclusion that if
> a driver is enabled in a defconfig file, it will be built.
defconfig files are virtually never a configuration for the kernel they
are shipped with since they aren't updated every time some configuration
option is changed.
Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
in this defconfig gets for some reason marked as broken in the Kconfig
file - this will give exactly the same result as the one you describe.
> Simon
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-13 14:00 ` Adrian Bunk
(?)
@ 2005-12-13 17:31 ` Russell King
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 17:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> defconfig files are virtually never a configuration for the kernel they
> are shipped with since they aren't updated every time some configuration
> option is changed.
>
> Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> in this defconfig gets for some reason marked as broken in the Kconfig
> file - this will give exactly the same result as the one you describe.
Adrian,
The defconfig files in arch/arm/configs are for platform configurations
and are provided by the platform maintainers as a _working_ configuration
for their platform. They're not "defconfigs". They got called
"defconfigs" as a result of the kbuild "cleanups". Please don't confuse
them as such.
If, in order to have a working platform configuration, they deem that
CONFIG_BROKEN must be enabled, then that's the way it is.
Therefore, I request that either you leave the ARM platform configurations
well alone, or follow the advice I've given so that we can _properly_
assess the impact of your changes.
Thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 17:31 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 17:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> defconfig files are virtually never a configuration for the kernel they
> are shipped with since they aren't updated every time some configuration
> option is changed.
>
> Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> in this defconfig gets for some reason marked as broken in the Kconfig
> file - this will give exactly the same result as the one you describe.
Adrian,
The defconfig files in arch/arm/configs are for platform configurations
and are provided by the platform maintainers as a _working_ configuration
for their platform. They're not "defconfigs". They got called
"defconfigs" as a result of the kbuild "cleanups". Please don't confuse
them as such.
If, in order to have a working platform configuration, they deem that
CONFIG_BROKEN must be enabled, then that's the way it is.
Therefore, I request that either you leave the ARM platform configurations
well alone, or follow the advice I've given so that we can _properly_
assess the impact of your changes.
Thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
@ 2005-12-13 17:31 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 17:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, paulus, linux-mtd, Simon Richter, dwmw2,
kkojima, parisc-linux
On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> defconfig files are virtually never a configuration for the kernel they
> are shipped with since they aren't updated every time some configuration
> option is changed.
>
> Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> in this defconfig gets for some reason marked as broken in the Kconfig
> file - this will give exactly the same result as the one you describe.
Adrian,
The defconfig files in arch/arm/configs are for platform configurations
and are provided by the platform maintainers as a _working_ configuration
for their platform. They're not "defconfigs". They got called
"defconfigs" as a result of the kbuild "cleanups". Please don't confuse
them as such.
If, in order to have a working platform configuration, they deem that
CONFIG_BROKEN must be enabled, then that's the way it is.
Therefore, I request that either you leave the ARM platform configurations
well alone, or follow the advice I've given so that we can _properly_
assess the impact of your changes.
Thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-13 17:31 ` Russell King
(?)
(?)
@ 2005-12-13 17:38 ` Geert Uytterhoeven
2005-12-13 19:53 ` Russell King
-1 siblings, 1 reply; 70+ messages in thread
From: Geert Uytterhoeven @ 2005-12-13 17:38 UTC (permalink / raw)
To: Russell King; +Cc: Adrian Bunk, Linux Kernel Development
On Tue, 13 Dec 2005, Russell King wrote:
> If, in order to have a working platform configuration, they deem that
^^^^^^^
> CONFIG_BROKEN must be enabled, then that's the way it is.
^^^^^^
Still funny...
So either one of them is lying...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 17:31 ` Russell King
(?)
@ 2005-12-13 18:05 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:05 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> > defconfig files are virtually never a configuration for the kernel they
> > are shipped with since they aren't updated every time some configuration
> > option is changed.
> >
> > Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> > in this defconfig gets for some reason marked as broken in the Kconfig
> > file - this will give exactly the same result as the one you describe.
>
> Adrian,
Hi Russell,
> The defconfig files in arch/arm/configs are for platform configurations
> and are provided by the platform maintainers as a _working_ configuration
> for their platform. They're not "defconfigs". They got called
> "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> them as such.
>
> If, in order to have a working platform configuration, they deem that
> CONFIG_BROKEN must be enabled, then that's the way it is.
if a working platform configuration configuration requires
CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
We are talking about a class of bugs that can usually be easily fixed if
reported - so why aren't they reported?
The MTD_SHARP case is a good example, because otherwise I might have
soon sent a patch that would have removed this driver with the rationale
"both marked as obsolete and BROKEN can clearly be removed".
> Therefore, I request that either you leave the ARM platform configurations
> well alone, or follow the advice I've given so that we can _properly_
> assess the impact of your changes.
Unless someone can tell me a valid case for enabling BROKEN that does
both create a working configuration and not hide real issues it seems
the approch below might be the way to go.
Yes, you might dislike this at the first sight.
But if you consider that although this might result in a short-term
breakage of some configurations, this will also result in proper bug
reports and fixing of the wrong BROKEN dependency bugs, I hope you agree
that this will actually improve the situation.
> Thanks.
cu
Adrian
<-- snip -->
Do not allow people to create configurations with CONFIG_BROKEN=y.
The sole reason for CONFIG_BROKEN=y would be if you are working on
fixing a broken driver, but in this case editing the Kconfig file is
trivial.
Never ever should a user enable CONFIG_BROKEN.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-rc5-mm2-full/init/Kconfig.old 2005-12-13 18:48:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/init/Kconfig 2005-12-13 18:48:52.000000000 +0100
@@ -31,19 +31,8 @@
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
-config CLEAN_COMPILE
- bool "Select only drivers expected to compile cleanly" if EXPERIMENTAL
- default y
- help
- Select this option if you don't even want to see the option
- to configure known-broken drivers.
-
- If unsure, say Y
-
config BROKEN
bool
- depends on !CLEAN_COMPILE
- default y
config BROKEN_ON_SMP
bool
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:05 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:05 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> > defconfig files are virtually never a configuration for the kernel they
> > are shipped with since they aren't updated every time some configuration
> > option is changed.
> >
> > Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> > in this defconfig gets for some reason marked as broken in the Kconfig
> > file - this will give exactly the same result as the one you describe.
>
> Adrian,
Hi Russell,
> The defconfig files in arch/arm/configs are for platform configurations
> and are provided by the platform maintainers as a _working_ configuration
> for their platform. They're not "defconfigs". They got called
> "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> them as such.
>
> If, in order to have a working platform configuration, they deem that
> CONFIG_BROKEN must be enabled, then that's the way it is.
if a working platform configuration configuration requires
CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
We are talking about a class of bugs that can usually be easily fixed if
reported - so why aren't they reported?
The MTD_SHARP case is a good example, because otherwise I might have
soon sent a patch that would have removed this driver with the rationale
"both marked as obsolete and BROKEN can clearly be removed".
> Therefore, I request that either you leave the ARM platform configurations
> well alone, or follow the advice I've given so that we can _properly_
> assess the impact of your changes.
Unless someone can tell me a valid case for enabling BROKEN that does
both create a working configuration and not hide real issues it seems
the approch below might be the way to go.
Yes, you might dislike this at the first sight.
But if you consider that although this might result in a short-term
breakage of some configurations, this will also result in proper bug
reports and fixing of the wrong BROKEN dependency bugs, I hope you agree
that this will actually improve the situation.
> Thanks.
cu
Adrian
<-- snip -->
Do not allow people to create configurations with CONFIG_BROKEN=y.
The sole reason for CONFIG_BROKEN=y would be if you are working on
fixing a broken driver, but in this case editing the Kconfig file is
trivial.
Never ever should a user enable CONFIG_BROKEN.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-rc5-mm2-full/init/Kconfig.old 2005-12-13 18:48:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/init/Kconfig 2005-12-13 18:48:52.000000000 +0100
@@ -31,19 +31,8 @@
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
-config CLEAN_COMPILE
- bool "Select only drivers expected to compile cleanly" if EXPERIMENTAL
- default y
- help
- Select this option if you don't even want to see the option
- to configure known-broken drivers.
-
- If unsure, say Y
-
config BROKEN
bool
- depends on !CLEAN_COMPILE
- default y
config BROKEN_ON_SMP
bool
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:05 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:05 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 03:00:01PM +0100, Adrian Bunk wrote:
> > defconfig files are virtually never a configuration for the kernel they
> > are shipped with since they aren't updated every time some configuration
> > option is changed.
> >
> > Consider a defconfig with CONFIG_BROKEN=n, and a driver that is enabled
> > in this defconfig gets for some reason marked as broken in the Kconfig
> > file - this will give exactly the same result as the one you describe.
>
> Adrian,
Hi Russell,
> The defconfig files in arch/arm/configs are for platform configurations
> and are provided by the platform maintainers as a _working_ configuration
> for their platform. They're not "defconfigs". They got called
> "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> them as such.
>
> If, in order to have a working platform configuration, they deem that
> CONFIG_BROKEN must be enabled, then that's the way it is.
if a working platform configuration configuration requires
CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
We are talking about a class of bugs that can usually be easily fixed if
reported - so why aren't they reported?
The MTD_SHARP case is a good example, because otherwise I might have
soon sent a patch that would have removed this driver with the rationale
"both marked as obsolete and BROKEN can clearly be removed".
> Therefore, I request that either you leave the ARM platform configurations
> well alone, or follow the advice I've given so that we can _properly_
> assess the impact of your changes.
Unless someone can tell me a valid case for enabling BROKEN that does
both create a working configuration and not hide real issues it seems
the approch below might be the way to go.
Yes, you might dislike this at the first sight.
But if you consider that although this might result in a short-term
breakage of some configurations, this will also result in proper bug
reports and fixing of the wrong BROKEN dependency bugs, I hope you agree
that this will actually improve the situation.
> Thanks.
cu
Adrian
<-- snip -->
Do not allow people to create configurations with CONFIG_BROKEN=y.
The sole reason for CONFIG_BROKEN=y would be if you are working on
fixing a broken driver, but in this case editing the Kconfig file is
trivial.
Never ever should a user enable CONFIG_BROKEN.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-rc5-mm2-full/init/Kconfig.old 2005-12-13 18:48:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/init/Kconfig 2005-12-13 18:48:52.000000000 +0100
@@ -31,19 +31,8 @@
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
-config CLEAN_COMPILE
- bool "Select only drivers expected to compile cleanly" if EXPERIMENTAL
- default y
- help
- Select this option if you don't even want to see the option
- to configure known-broken drivers.
-
- If unsure, say Y
-
config BROKEN
bool
- depends on !CLEAN_COMPILE
- default y
config BROKEN_ON_SMP
bool
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 18:05 ` Adrian Bunk
(?)
(?)
@ 2005-12-13 18:28 ` Geert Uytterhoeven
-1 siblings, 0 replies; 70+ messages in thread
From: Geert Uytterhoeven @ 2005-12-13 18:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: Simon Richter, Linux Kernel Development, tony.luck, linux-ia64,
matthew, grundler, parisc-linux, Paul Mackerras,
Linux/PPC Development, lethal, kkojima, dwmw2, linux-mtd
On Tue, 13 Dec 2005, Adrian Bunk wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
^^^^
OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
But I'd like to at least have the possibility to enable broken drivers, even if
it's just for compile regression tests.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:28 ` Geert Uytterhoeven
0 siblings, 0 replies; 70+ messages in thread
From: Geert Uytterhoeven @ 2005-12-13 18:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Linux/PPC Development, lethal,
linux-mtd, dwmw2, kkojima, parisc-linux
On Tue, 13 Dec 2005, Adrian Bunk wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
^^^^
OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
But I'd like to at least have the possibility to enable broken drivers, even if
it's just for compile regression tests.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:28 ` Geert Uytterhoeven
0 siblings, 0 replies; 70+ messages in thread
From: Geert Uytterhoeven @ 2005-12-13 18:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Linux/PPC Development, lethal,
Paul Mackerras, linux-mtd, Simon Richter, dwmw2, kkojima,
parisc-linux
On Tue, 13 Dec 2005, Adrian Bunk wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
^^^^
OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
But I'd like to at least have the possibility to enable broken drivers, even if
it's just for compile regression tests.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:28 ` Geert Uytterhoeven
0 siblings, 0 replies; 70+ messages in thread
From: Geert Uytterhoeven @ 2005-12-13 18:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: Simon Richter, Linux Kernel Development, tony.luck, linux-ia64,
matthew, grundler, parisc-linux, Paul Mackerras,
Linux/PPC Development, lethal, kkojima, dwmw2, linux-mtd
On Tue, 13 Dec 2005, Adrian Bunk wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
^^^^
OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
But I'd like to at least have the possibility to enable broken drivers, even if
it's just for compile regression tests.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 18:28 ` Geert Uytterhoeven
(?)
(?)
@ 2005-12-13 18:51 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Richter, Linux Kernel Development, tony.luck, linux-ia64,
matthew, grundler, parisc-linux, Paul Mackerras,
Linux/PPC Development, lethal, kkojima, dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 07:28:41PM +0100, Geert Uytterhoeven wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
Let's assume users don't have any hardware (e.g. several SATA drivers)
that requires EXPERIMENTAL...
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
If a kernel developer really wants to enable BROKEN drivers, my patch
still gives them the possibility to do so with a trivial edit of
init/Kconfig.
> Gr{oetje,eeting}s,
>
> Geert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:51 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Linux/PPC Development, lethal,
linux-mtd, dwmw2, kkojima, parisc-linux
On Tue, Dec 13, 2005 at 07:28:41PM +0100, Geert Uytterhoeven wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
Let's assume users don't have any hardware (e.g. several SATA drivers)
that requires EXPERIMENTAL...
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
If a kernel developer really wants to enable BROKEN drivers, my patch
still gives them the possibility to do so with a trivial edit of
init/Kconfig.
> Gr{oetje,eeting}s,
>
> Geert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:51 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Linux/PPC Development, lethal,
Paul Mackerras, linux-mtd, Simon Richter, dwmw2, kkojima,
parisc-linux
On Tue, Dec 13, 2005 at 07:28:41PM +0100, Geert Uytterhoeven wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
Let's assume users don't have any hardware (e.g. several SATA drivers)
that requires EXPERIMENTAL...
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
If a kernel developer really wants to enable BROKEN drivers, my patch
still gives them the possibility to do so with a trivial edit of
init/Kconfig.
> Gr{oetje,eeting}s,
>
> Geert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:51 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 18:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Richter, Linux Kernel Development, tony.luck, linux-ia64,
matthew, grundler, parisc-linux, Paul Mackerras,
Linux/PPC Development, lethal, kkojima, dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 07:28:41PM +0100, Geert Uytterhoeven wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
Let's assume users don't have any hardware (e.g. several SATA drivers)
that requires EXPERIMENTAL...
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
If a kernel developer really wants to enable BROKEN drivers, my patch
still gives them the possibility to do so with a trivial edit of
init/Kconfig.
> Gr{oetje,eeting}s,
>
> Geert
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 18:28 ` Geert Uytterhoeven
(?)
(?)
@ 2005-12-13 18:59 ` Jesper Juhl
-1 siblings, 0 replies; 70+ messages in thread
From: Jesper Juhl @ 2005-12-13 18:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Adrian Bunk, Simon Richter, Linux Kernel Development, tony.luck,
linux-ia64, matthew, grundler, parisc-linux, Paul Mackerras,
Linux/PPC Development, lethal, kkojima, dwmw2, linux-mtd
On 12/13/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
>
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
>
I agree, and it's very convenient to be able to enable it in
menuconfig etc. Perhaps CONFIG_BROKEN should just be moved to kernel
hacking instead...?
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:59 ` Jesper Juhl
0 siblings, 0 replies; 70+ messages in thread
From: Jesper Juhl @ 2005-12-13 18:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Adrian Bunk, Linux/PPC Development,
lethal, linux-mtd, dwmw2, kkojima, parisc-linux
On 12/13/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=3Dy.
> >
> > The sole reason for CONFIG_BROKEN=3Dy would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
>
> But I'd like to at least have the possibility to enable broken drivers, e=
ven if
> it's just for compile regression tests.
>
I agree, and it's very convenient to be able to enable it in
menuconfig etc. Perhaps CONFIG_BROKEN should just be moved to kernel
hacking instead...?
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:59 ` Jesper Juhl
0 siblings, 0 replies; 70+ messages in thread
From: Jesper Juhl @ 2005-12-13 18:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tony.luck, linux-ia64, grundler, matthew,
Linux Kernel Development, Adrian Bunk, Linux/PPC Development,
lethal, Paul Mackerras, linux-mtd, Simon Richter, dwmw2, kkojima,
parisc-linux
On 12/13/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
>
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
>
I agree, and it's very convenient to be able to enable it in
menuconfig etc. Perhaps CONFIG_BROKEN should just be moved to kernel
hacking instead...?
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 18:59 ` Jesper Juhl
0 siblings, 0 replies; 70+ messages in thread
From: Jesper Juhl @ 2005-12-13 18:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Adrian Bunk, Simon Richter, Linux Kernel Development, tony.luck,
linux-ia64, matthew, grundler, parisc-linux, Paul Mackerras,
Linux/PPC Development, lethal, kkojima, dwmw2, linux-mtd
On 12/13/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 13 Dec 2005, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> ^^^^
> OK, a user, not an expert. Let's assume users don't enable EXPERIMENTAL.
>
> But I'd like to at least have the possibility to enable broken drivers, even if
> it's just for compile regression tests.
>
I agree, and it's very convenient to be able to enable it in
menuconfig etc. Perhaps CONFIG_BROKEN should just be moved to kernel
hacking instead...?
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-13 17:38 ` Geert Uytterhoeven
@ 2005-12-13 19:53 ` Russell King
2005-12-13 20:09 ` Adrian Bunk
0 siblings, 1 reply; 70+ messages in thread
From: Russell King @ 2005-12-13 19:53 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Adrian Bunk, Linux Kernel Development
On Tue, Dec 13, 2005 at 06:38:36PM +0100, Geert Uytterhoeven wrote:
> On Tue, 13 Dec 2005, Russell King wrote:
> > If, in order to have a working platform configuration, they deem that
> ^^^^^^^
> > CONFIG_BROKEN must be enabled, then that's the way it is.
> ^^^^^^
> Still funny...
>
> So either one of them is lying...
They might be broken in other situations. However, if you look at
the latest build at:
http://armlinux.simtec.co.uk/kautobuild/
you'll notice that all, even the ones with CONFIG_BROKEN build
successfully. Without any bug reports to the contary, we must
assume that the configuration files supplied by the folk who
developed the support for the platform are correct and working.
Therefore, CONFIG_BROKEN may have been added to configuration
options which don't work for some particular small corner cases.
This brings on to another subject. If we mark something broken
we should say _why_ we're doing so, especially if it is non-obvious.
That seems to be the case here - if these drivers are broken, it's
non-obvious why they're broken.
So, all in all, CONFIG_BROKEN is a broken idea in itself!
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 18:05 ` Adrian Bunk
(?)
@ 2005-12-13 20:01 ` Russell King
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 20:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > The defconfig files in arch/arm/configs are for platform configurations
> > and are provided by the platform maintainers as a _working_ configuration
> > for their platform. They're not "defconfigs". They got called
> > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > them as such.
> >
> > If, in order to have a working platform configuration, they deem that
> > CONFIG_BROKEN must be enabled, then that's the way it is.
>
> if a working platform configuration configuration requires
> CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
Maybe they're only broken for a small subset of platforms, and someone
added a BROKEN without properly considering whether it should be global
or not?
I don't disagree with the overall notion that CONFIG_BROKEN should not
be set _where_ _possible_. However, if it needs to be set to get the
required options, then that's what needs to happen until such time that
the above is corrected.
However - and now to the main bug bear - how can we tell what is really
broken if you _just_ change the default configuration file settings for
CONFIG_BROKEN? What happens is that, on review, we see a simple change.
We'd assume that it has little impact, and we accept that change.
Maybe a month or two down the line, someone whines that their platform
doesn't work for some reason, and it's tracked down to this and the
resulting fallout from disabling CONFIG_BROKEN.
That means that the original review was _worthless_. It wasn't a
review at all.
So, what I am trying to get across is the need to show the _full_ set
of changes to a default configuratoin when you disable CONFIG_BROKEN,
which is trivially producable if you run the script I've already posted.
You can even use that in conjunction with your present patch to produce
a patch which shows _exactly_ _everything_ which changes as a result of
disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
far better than half a story, and should be something that any change
to the kernel strives for.
If not, what's the point of the original change?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 20:01 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 20:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > The defconfig files in arch/arm/configs are for platform configurations
> > and are provided by the platform maintainers as a _working_ configuration
> > for their platform. They're not "defconfigs". They got called
> > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > them as such.
> >
> > If, in order to have a working platform configuration, they deem that
> > CONFIG_BROKEN must be enabled, then that's the way it is.
>
> if a working platform configuration configuration requires
> CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
Maybe they're only broken for a small subset of platforms, and someone
added a BROKEN without properly considering whether it should be global
or not?
I don't disagree with the overall notion that CONFIG_BROKEN should not
be set _where_ _possible_. However, if it needs to be set to get the
required options, then that's what needs to happen until such time that
the above is corrected.
However - and now to the main bug bear - how can we tell what is really
broken if you _just_ change the default configuration file settings for
CONFIG_BROKEN? What happens is that, on review, we see a simple change.
We'd assume that it has little impact, and we accept that change.
Maybe a month or two down the line, someone whines that their platform
doesn't work for some reason, and it's tracked down to this and the
resulting fallout from disabling CONFIG_BROKEN.
That means that the original review was _worthless_. It wasn't a
review at all.
So, what I am trying to get across is the need to show the _full_ set
of changes to a default configuratoin when you disable CONFIG_BROKEN,
which is trivially producable if you run the script I've already posted.
You can even use that in conjunction with your present patch to produce
a patch which shows _exactly_ _everything_ which changes as a result of
disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
far better than half a story, and should be something that any change
to the kernel strives for.
If not, what's the point of the original change?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 20:01 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 20:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, paulus, linux-mtd, Simon Richter, dwmw2,
kkojima, parisc-linux
On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > The defconfig files in arch/arm/configs are for platform configurations
> > and are provided by the platform maintainers as a _working_ configuration
> > for their platform. They're not "defconfigs". They got called
> > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > them as such.
> >
> > If, in order to have a working platform configuration, they deem that
> > CONFIG_BROKEN must be enabled, then that's the way it is.
>
> if a working platform configuration configuration requires
> CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
Maybe they're only broken for a small subset of platforms, and someone
added a BROKEN without properly considering whether it should be global
or not?
I don't disagree with the overall notion that CONFIG_BROKEN should not
be set _where_ _possible_. However, if it needs to be set to get the
required options, then that's what needs to happen until such time that
the above is corrected.
However - and now to the main bug bear - how can we tell what is really
broken if you _just_ change the default configuration file settings for
CONFIG_BROKEN? What happens is that, on review, we see a simple change.
We'd assume that it has little impact, and we accept that change.
Maybe a month or two down the line, someone whines that their platform
doesn't work for some reason, and it's tracked down to this and the
resulting fallout from disabling CONFIG_BROKEN.
That means that the original review was _worthless_. It wasn't a
review at all.
So, what I am trying to get across is the need to show the _full_ set
of changes to a default configuratoin when you disable CONFIG_BROKEN,
which is trivially producable if you run the script I've already posted.
You can even use that in conjunction with your present patch to produce
a patch which shows _exactly_ _everything_ which changes as a result of
disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
far better than half a story, and should be something that any change
to the kernel strives for.
If not, what's the point of the original change?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-13 19:53 ` Russell King
@ 2005-12-13 20:09 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 20:09 UTC (permalink / raw)
To: Geert Uytterhoeven, Linux Kernel Development
On Tue, Dec 13, 2005 at 07:53:14PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 06:38:36PM +0100, Geert Uytterhoeven wrote:
> > On Tue, 13 Dec 2005, Russell King wrote:
> > > If, in order to have a working platform configuration, they deem that
> > ^^^^^^^
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> > ^^^^^^
> > Still funny...
> >
> > So either one of them is lying...
>
> They might be broken in other situations. However, if you look at
> the latest build at:
>
> http://armlinux.simtec.co.uk/kautobuild/
>
> you'll notice that all, even the ones with CONFIG_BROKEN build
> successfully. Without any bug reports to the contary, we must
> assume that the configuration files supplied by the folk who
> developed the support for the platform are correct and working.
The bug in this case was the (implicit) BROKEN dependency of MTD_SHARP.
> Therefore, CONFIG_BROKEN may have been added to configuration
> options which don't work for some particular small corner cases.
Such corner cases could easily be handled using
depends on (BROKEN || SA1100_COLLIE)
Or in other cases wie have
depends on (BROKEN || !64BIT)
If it works its not BROKEN, and we can express this.
> This brings on to another subject. If we mark something broken
> we should say _why_ we're doing so, especially if it is non-obvious.
> That seems to be the case here - if these drivers are broken, it's
> non-obvious why they're broken.
The vast majority of drivers depending on BROKEN simply don't compile.
How many examples besides MTD_SHARP can you name where you have problems
to determine why something is marked as BROKEN?
> So, all in all, CONFIG_BROKEN is a broken idea in itself!
The idea behind BROKEN is to not offer drivers where we know that they
don't compile or will for sure not work to users.
The ARM case that people are using the supplied defconfig's more or less
unchanged is a big exception.
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 20:01 ` Russell King
(?)
@ 2005-12-13 20:19 ` Adrian Bunk
-1 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 20:19 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> > On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > > The defconfig files in arch/arm/configs are for platform configurations
> > > and are provided by the platform maintainers as a _working_ configuration
> > > for their platform. They're not "defconfigs". They got called
> > > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > > them as such.
> > >
> > > If, in order to have a working platform configuration, they deem that
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> >
> > if a working platform configuration configuration requires
> > CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
>
> Maybe they're only broken for a small subset of platforms, and someone
> added a BROKEN without properly considering whether it should be global
> or not?
>
> I don't disagree with the overall notion that CONFIG_BROKEN should not
> be set _where_ _possible_. However, if it needs to be set to get the
> required options, then that's what needs to happen until such time that
> the above is corrected.
Where is the bug report from the person who set CONFIG_BROKEN=y in the
collie defconfig that the BROKEN dependency on MTD_SHARP was wrong?
> However - and now to the main bug bear - how can we tell what is really
> broken if you _just_ change the default configuration file settings for
> CONFIG_BROKEN? What happens is that, on review, we see a simple change.
> We'd assume that it has little impact, and we accept that change.
>
> Maybe a month or two down the line, someone whines that their platform
> doesn't work for some reason, and it's tracked down to this and the
> resulting fallout from disabling CONFIG_BROKEN.
The whining is the bug report the person who set the CONFIG_BROKEN=y in
the defconfig didn't send.
And things would have been even worse if I had sent a patch erasing
MTD_SHARP from the kernel because code "both marked as obsolete and
BROKEN can clearly be removed" and the code was therefore completely
removed two months before the first person whined?
> That means that the original review was _worthless_. It wasn't a
> review at all.
>
> So, what I am trying to get across is the need to show the _full_ set
> of changes to a default configuratoin when you disable CONFIG_BROKEN,
> which is trivially producable if you run the script I've already posted.
>
> You can even use that in conjunction with your present patch to produce
> a patch which shows _exactly_ _everything_ which changes as a result of
> disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> far better than half a story, and should be something that any change
> to the kernel strives for.
>
> If not, what's the point of the original change?
The point is that I haven't yet heard any good reason for
CONFIG_BROKEN=y in a defconfig.
No, it's not a good reason if someone used it as a workaround instead of
sending a bug report that would result in a fixing of the wrong BROKEN
dependency.
Where is the bug report of the person setting CONFIG_BROKEN=y in the
collie defconfig that the MTD_SHARP dependency on BROKEN was wrong?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 20:19 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 20:19 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> > On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > > The defconfig files in arch/arm/configs are for platform configurations
> > > and are provided by the platform maintainers as a _working_ configuration
> > > for their platform. They're not "defconfigs". They got called
> > > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > > them as such.
> > >
> > > If, in order to have a working platform configuration, they deem that
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> >
> > if a working platform configuration configuration requires
> > CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
>
> Maybe they're only broken for a small subset of platforms, and someone
> added a BROKEN without properly considering whether it should be global
> or not?
>
> I don't disagree with the overall notion that CONFIG_BROKEN should not
> be set _where_ _possible_. However, if it needs to be set to get the
> required options, then that's what needs to happen until such time that
> the above is corrected.
Where is the bug report from the person who set CONFIG_BROKEN=y in the
collie defconfig that the BROKEN dependency on MTD_SHARP was wrong?
> However - and now to the main bug bear - how can we tell what is really
> broken if you _just_ change the default configuration file settings for
> CONFIG_BROKEN? What happens is that, on review, we see a simple change.
> We'd assume that it has little impact, and we accept that change.
>
> Maybe a month or two down the line, someone whines that their platform
> doesn't work for some reason, and it's tracked down to this and the
> resulting fallout from disabling CONFIG_BROKEN.
The whining is the bug report the person who set the CONFIG_BROKEN=y in
the defconfig didn't send.
And things would have been even worse if I had sent a patch erasing
MTD_SHARP from the kernel because code "both marked as obsolete and
BROKEN can clearly be removed" and the code was therefore completely
removed two months before the first person whined?
> That means that the original review was _worthless_. It wasn't a
> review at all.
>
> So, what I am trying to get across is the need to show the _full_ set
> of changes to a default configuratoin when you disable CONFIG_BROKEN,
> which is trivially producable if you run the script I've already posted.
>
> You can even use that in conjunction with your present patch to produce
> a patch which shows _exactly_ _everything_ which changes as a result of
> disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> far better than half a story, and should be something that any change
> to the kernel strives for.
>
> If not, what's the point of the original change?
The point is that I haven't yet heard any good reason for
CONFIG_BROKEN=y in a defconfig.
No, it's not a good reason if someone used it as a workaround instead of
sending a bug report that would result in a fixing of the wrong BROKEN
dependency.
Where is the bug report of the person setting CONFIG_BROKEN=y in the
collie defconfig that the MTD_SHARP dependency on BROKEN was wrong?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 20:19 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2005-12-13 20:19 UTC (permalink / raw)
To: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> > On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > > The defconfig files in arch/arm/configs are for platform configurations
> > > and are provided by the platform maintainers as a _working_ configuration
> > > for their platform. They're not "defconfigs". They got called
> > > "defconfigs" as a result of the kbuild "cleanups". Please don't confuse
> > > them as such.
> > >
> > > If, in order to have a working platform configuration, they deem that
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> >
> > if a working platform configuration configuration requires
> > CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
>
> Maybe they're only broken for a small subset of platforms, and someone
> added a BROKEN without properly considering whether it should be global
> or not?
>
> I don't disagree with the overall notion that CONFIG_BROKEN should not
> be set _where_ _possible_. However, if it needs to be set to get the
> required options, then that's what needs to happen until such time that
> the above is corrected.
Where is the bug report from the person who set CONFIG_BROKEN=y in the
collie defconfig that the BROKEN dependency on MTD_SHARP was wrong?
> However - and now to the main bug bear - how can we tell what is really
> broken if you _just_ change the default configuration file settings for
> CONFIG_BROKEN? What happens is that, on review, we see a simple change.
> We'd assume that it has little impact, and we accept that change.
>
> Maybe a month or two down the line, someone whines that their platform
> doesn't work for some reason, and it's tracked down to this and the
> resulting fallout from disabling CONFIG_BROKEN.
The whining is the bug report the person who set the CONFIG_BROKEN=y in
the defconfig didn't send.
And things would have been even worse if I had sent a patch erasing
MTD_SHARP from the kernel because code "both marked as obsolete and
BROKEN can clearly be removed" and the code was therefore completely
removed two months before the first person whined?
> That means that the original review was _worthless_. It wasn't a
> review at all.
>
> So, what I am trying to get across is the need to show the _full_ set
> of changes to a default configuratoin when you disable CONFIG_BROKEN,
> which is trivially producable if you run the script I've already posted.
>
> You can even use that in conjunction with your present patch to produce
> a patch which shows _exactly_ _everything_ which changes as a result of
> disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> far better than half a story, and should be something that any change
> to the kernel strives for.
>
> If not, what's the point of the original change?
The point is that I haven't yet heard any good reason for
CONFIG_BROKEN=y in a defconfig.
No, it's not a good reason if someone used it as a workaround instead of
sending a bug report that would result in a fixing of the wrong BROKEN
dependency.
Where is the bug report of the person setting CONFIG_BROKEN=y in the
collie defconfig that the MTD_SHARP dependency on BROKEN was wrong?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2005-12-13 20:19 ` Adrian Bunk
(?)
@ 2005-12-13 22:01 ` Russell King
-1 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 22:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: Simon Richter, linux-kernel, tony.luck, linux-ia64, matthew,
grundler, parisc-linux, paulus, linuxppc-dev, lethal, kkojima,
dwmw2, linux-mtd
On Tue, Dec 13, 2005 at 09:19:20PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> > That means that the original review was _worthless_. It wasn't a
> > review at all.
> >
> > So, what I am trying to get across is the need to show the _full_ set
> > of changes to a default configuratoin when you disable CONFIG_BROKEN,
> > which is trivially producable if you run the script I've already posted.
> >
> > You can even use that in conjunction with your present patch to produce
> > a patch which shows _exactly_ _everything_ which changes as a result of
> > disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> > far better than half a story, and should be something that any change
> > to the kernel strives for.
> >
> > If not, what's the point of the original change?
>
> The point is that I haven't yet heard any good reason for
> CONFIG_BROKEN=y in a defconfig.
I'm sorry, I feel like I'm beating my head against a brick wall. I
have said everything that needs to be said, and made my position on
this patch crystal clear.
The patch to the ARM configuration files is nacked as it stands.
Please go back and rework it along the guidelines I've pointed out
several times in this thread and maybe then it becomes acceptable.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 22:01 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 22:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, linux-mtd, dwmw2, kkojima, parisc-linux
On Tue, Dec 13, 2005 at 09:19:20PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> > That means that the original review was _worthless_. It wasn't a
> > review at all.
> >
> > So, what I am trying to get across is the need to show the _full_ set
> > of changes to a default configuratoin when you disable CONFIG_BROKEN,
> > which is trivially producable if you run the script I've already posted.
> >
> > You can even use that in conjunction with your present patch to produce
> > a patch which shows _exactly_ _everything_ which changes as a result of
> > disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> > far better than half a story, and should be something that any change
> > to the kernel strives for.
> >
> > If not, what's the point of the original change?
>
> The point is that I haven't yet heard any good reason for
> CONFIG_BROKEN=y in a defconfig.
I'm sorry, I feel like I'm beating my head against a brick wall. I
have said everything that needs to be said, and made my position on
this patch crystal clear.
The patch to the ARM configuration files is nacked as it stands.
Please go back and rework it along the guidelines I've pointed out
several times in this thread and maybe then it becomes acceptable.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2005-12-13 22:01 ` Russell King
0 siblings, 0 replies; 70+ messages in thread
From: Russell King @ 2005-12-13 22:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, paulus, linux-mtd, Simon Richter, dwmw2,
kkojima, parisc-linux
On Tue, Dec 13, 2005 at 09:19:20PM +0100, Adrian Bunk wrote:
> On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> > That means that the original review was _worthless_. It wasn't a
> > review at all.
> >
> > So, what I am trying to get across is the need to show the _full_ set
> > of changes to a default configuratoin when you disable CONFIG_BROKEN,
> > which is trivially producable if you run the script I've already posted.
> >
> > You can even use that in conjunction with your present patch to produce
> > a patch which shows _exactly_ _everything_ which changes as a result of
> > disabling CONFIG_BROKEN. Surely giving reviewers the _full_ story is
> > far better than half a story, and should be something that any change
> > to the kernel strives for.
> >
> > If not, what's the point of the original change?
>
> The point is that I haven't yet heard any good reason for
> CONFIG_BROKEN=y in a defconfig.
I'm sorry, I feel like I'm beating my head against a brick wall. I
have said everything that needs to be said, and made my position on
this patch crystal clear.
The patch to the ARM configuration files is nacked as it stands.
Please go back and rework it along the guidelines I've pointed out
several times in this thread and maybe then it becomes acceptable.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
2005-12-12 9:38 ` David Woodhouse
` (2 preceding siblings ...)
(?)
@ 2005-12-14 11:50 ` Richard Purdie
-1 siblings, 0 replies; 70+ messages in thread
From: Richard Purdie @ 2005-12-14 11:50 UTC (permalink / raw)
To: David Woodhouse, Adrian Bunk; +Cc: linux-kernel, Russell King
On Mon, 2005-12-12 at 10:38 +0100, David Woodhouse wrote:
> On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> > Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> > which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> > or the dependency on BROKEN is not correct and should be corrected.
> >
> > David, can you comment on this issue?
>
> I don't see any justification for MTD_OBSOLETE_CHIPS depending on
> BROKEN. That option covers a few of the obsolete chip drivers which
> people shouldn't be using any more -- and I'm perfectly willing to
> believe that one or two of those don't work any more, but if that's the
> case then those individual drivers ought to be marked BROKEN (or just
> removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
>
> I'd like to see the collie_defconfig updated to use the appropriate CFI
> driver back end.
As things stand, collie doesn't work with the unmodified mainline
obsolete chips driver but doesn't work with CFI either. Updating the
defconfig isn't really going to help one way or the other as both are
broken in some way.
A patch does exist to make the obsolete chip driver work on collie and
it could probably be made acceptable to mainline but I doubt David would
apply it as he (understandably) wants the "obsolete" driver to die.
I'm just a spectator in this as I don't have access to hardware to work
out what the problem with CFI is. I agree CFI is the way to go but until
it works, every real world configuration is going to use the patched
obsolete driver.
Adrian Bunk:
> The vast majority of drivers depending on BROKEN simply don't compile.
In this case the sharp driver didn't use to compile but does now since
my patch to fix it was applied. If broken means doesn't compile, the
driver does now and the broken status can be removed. It should work on
the platforms it originally worked on. It is still missing some code
that's needed to make it work specifically on collie but I guess that's
a separate issue.
Richard
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2006-01-19 1:40 Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2006-01-19 1:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Do not allow people to create configurations with CONFIG_BROKEN=y.
The sole reason for CONFIG_BROKEN=y would be if you are working on
fixing a broken driver, but in this case editing the Kconfig file is
trivial.
Never ever should a user enable CONFIG_BROKEN.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 6 Jan 2006
- 13 Dec 2005
--- linux-2.6.15-rc5-mm2-full/init/Kconfig.old 2005-12-13 18:48:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/init/Kconfig 2005-12-13 18:48:52.000000000 +0100
@@ -31,19 +31,8 @@
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
-config CLEAN_COMPILE
- bool "Select only drivers expected to compile cleanly" if EXPERIMENTAL
- default y
- help
- Select this option if you don't even want to see the option
- to configure known-broken drivers.
-
- If unsure, say Y
-
config BROKEN
bool
- depends on !CLEAN_COMPILE
- default y
config BROKEN_ON_SMP
bool
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 22:39 ` David Lang
@ 2006-01-06 22:53 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2006-01-06 22:53 UTC (permalink / raw)
To: David Lang; +Cc: Jesper Juhl, Andrew Morton, linux-kernel
On Fri, Jan 06, 2006 at 02:39:34PM -0800, David Lang wrote:
> On Fri, 6 Jan 2006, Adrian Bunk wrote:
>
> >
> >On Fri, Jan 06, 2006 at 01:11:17PM -0800, David Lang wrote:
> >>On Fri, 6 Jan 2006, Adrian Bunk wrote:
> >>...
> >>>>- Being able to easily enable it in menuconfig, then browse through
> >>>>the menus to look for something matching your hardware is nice, even
> >>>>if that something is marked BROKEN at least you've then found a place
> >>>>to start working on. A lot simpler than digging through directories.
> >>>
> >>>Our menus are mostly made for _users_.
> >>
> >>true, but do you really want to raise the barrier for users to test
> >>things? or do you intend to have a bunch of patches that remove BROKEN for
> >>a config option so that people can test them during the -rc and then add
> >>it back for them all before a real release?
> >
> >If an option is untested it's EXPERIMENTAL.
> >If it's broken it's BROKEN.
> >
> >If an option is marked as BROKEN but works fine for you please send a
> >bug report.
>
> my point is that if someone sends a patch that they think will fix
> something, nobody will be able to test that patch unless they are willing
> to edit their kconfig file unless the patch also marks it unbroken before
> anyone else has tested it.
Kernel developers usually aren't _that_ dumb:
The patch that fixes the driver simply removes the dependency on BROKEN.
> David Lang
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 22:37 ` Adrian Bunk
@ 2006-01-06 22:39 ` David Lang
2006-01-06 22:53 ` Adrian Bunk
0 siblings, 1 reply; 70+ messages in thread
From: David Lang @ 2006-01-06 22:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Jesper Juhl, Andrew Morton, linux-kernel
On Fri, 6 Jan 2006, Adrian Bunk wrote:
>
> On Fri, Jan 06, 2006 at 01:11:17PM -0800, David Lang wrote:
>> On Fri, 6 Jan 2006, Adrian Bunk wrote:
>> ...
>>>> - Being able to easily enable it in menuconfig, then browse through
>>>> the menus to look for something matching your hardware is nice, even
>>>> if that something is marked BROKEN at least you've then found a place
>>>> to start working on. A lot simpler than digging through directories.
>>>
>>> Our menus are mostly made for _users_.
>>
>> true, but do you really want to raise the barrier for users to test
>> things? or do you intend to have a bunch of patches that remove BROKEN for
>> a config option so that people can test them during the -rc and then add
>> it back for them all before a real release?
>
> If an option is untested it's EXPERIMENTAL.
> If it's broken it's BROKEN.
>
> If an option is marked as BROKEN but works fine for you please send a
> bug report.
my point is that if someone sends a patch that they think will fix
something, nobody will be able to test that patch unless they are willing
to edit their kconfig file unless the patch also marks it unbroken before
anyone else has tested it.
David Lang
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 21:11 ` David Lang
@ 2006-01-06 22:37 ` Adrian Bunk
2006-01-06 22:39 ` David Lang
0 siblings, 1 reply; 70+ messages in thread
From: Adrian Bunk @ 2006-01-06 22:37 UTC (permalink / raw)
To: David Lang; +Cc: Jesper Juhl, Andrew Morton, linux-kernel
On Fri, Jan 06, 2006 at 01:11:17PM -0800, David Lang wrote:
> On Fri, 6 Jan 2006, Adrian Bunk wrote:
>...
> >>- Being able to easily enable it in menuconfig, then browse through
> >>the menus to look for something matching your hardware is nice, even
> >>if that something is marked BROKEN at least you've then found a place
> >>to start working on. A lot simpler than digging through directories.
> >
> >Our menus are mostly made for _users_.
>
> true, but do you really want to raise the barrier for users to test
> things? or do you intend to have a bunch of patches that remove BROKEN for
> a config option so that people can test them during the -rc and then add
> it back for them all before a real release?
If an option is untested it's EXPERIMENTAL.
If it's broken it's BROKEN.
If an option is marked as BROKEN but works fine for you please send a
bug report.
> >The more common are users accidentially enabling CONFIG_BROKEN and then
> >wondering why a driver isn't compiling or working.
> >
> >And in my experience, when searching whether hardware might be supported
> >a grep through the kernel sources brings you more than reading often
> >outdated Kconfig help texts. Besides this, a BROKEN driver usually has
> >the same value for the user as a non-existing driver.
>
> it depends on how broken something really is, in some cases you are
> correct, in others you aren't.
It's so broken that a devloper said EXPERIMENTAL is not enough, users
should really not see it. Often the developer additionall added an
#error to the driver.
>...
> >If you know the driver is marked as BROKEN and if you want to use it
> >despite this, editing the Kconfig file is trivial.
> >
> >Unless you _really_ know what you are doing, no driver for your hard
> >disk is better than a broken driver.
>
> for your hard drive you are probably right, but does this always apply for
> your network card? or your sound card?
>...
It might be marked as BROKEN because it crashes the kernel.
But well, the common case is that the code marked as BROKEN simply
doesn't compile.
> David Lang
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 17:49 ` Jesper Juhl
2006-01-06 18:06 ` Adrian Bunk
@ 2006-01-06 22:25 ` Daniel Barkalow
1 sibling, 0 replies; 70+ messages in thread
From: Daniel Barkalow @ 2006-01-06 22:25 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Adrian Bunk, Andrew Morton, linux-kernel
On Fri, 6 Jan 2006, Jesper Juhl wrote:
> On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> >
> I disagree (slightly) with this patch for a few reasons:
>
> - It's very convenient to be able to enable it through menuconfig.
>
> - Being able to easily enable it in menuconfig, then browse through
> the menus to look for something matching your hardware is nice, even
> if that something is marked BROKEN at least you've then found a place
> to start working on. A lot simpler than digging through directories.
It might be nice if you could enable "show BROKEN" options, and have them
appear in the list without being able to select them...
> - Some things marked BROKEN may not be 100% broken and may actually
> work for some specific things, so if you know that it works for your
> use, then being able to easily enable BROKEN and then whatever it is
> you need is nice.
But then you can accidentally enable something else that really is broken
in the way you're going to use it. What you really want is to be able to
override the BROKEN marking on individual options, not to override all
BROKEN markings. Perhaps there should be a way to enable an option with
unmet dependencies, such that the dependencies are treated as enabled for
the purpose of building, but not for the purpose of making options that
also depend on the same things available. This would also be nice for the
case where you don't generally want EXPERIMENTAL drivers, but you do want
a particular one that you've personally found to be stable.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 18:06 ` Adrian Bunk
2006-01-06 18:26 ` Jesper Juhl
@ 2006-01-06 21:11 ` David Lang
2006-01-06 22:37 ` Adrian Bunk
1 sibling, 1 reply; 70+ messages in thread
From: David Lang @ 2006-01-06 21:11 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Jesper Juhl, Andrew Morton, linux-kernel
On Fri, 6 Jan 2006, Adrian Bunk wrote:
> On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
>> On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
>>> Do not allow people to create configurations with CONFIG_BROKEN=y.
>>>
>>> The sole reason for CONFIG_BROKEN=y would be if you are working on
>>> fixing a broken driver, but in this case editing the Kconfig file is
>>> trivial.
>>>
>>> Never ever should a user enable CONFIG_BROKEN.
>>>
>> I disagree (slightly) with this patch for a few reasons:
>>
>> - It's very convenient to be able to enable it through menuconfig.
>
> And when do you really need it?
at various times over the years I've needed it to enable partially working
drivers for several things.
>> - Being able to easily enable it in menuconfig, then browse through
>> the menus to look for something matching your hardware is nice, even
>> if that something is marked BROKEN at least you've then found a place
>> to start working on. A lot simpler than digging through directories.
>
> Our menus are mostly made for _users_.
true, but do you really want to raise the barrier for users to test
things? or do you intend to have a bunch of patches that remove BROKEN for
a config option so that people can test them during the -rc and then add
it back for them all before a real release?
> The more common are users accidentially enabling CONFIG_BROKEN and then
> wondering why a driver isn't compiling or working.
>
> And in my experience, when searching whether hardware might be supported
> a grep through the kernel sources brings you more than reading often
> outdated Kconfig help texts. Besides this, a BROKEN driver usually has
> the same value for the user as a non-existing driver.
it depends on how broken something really is, in some cases you are
correct, in others you aren't.
>> - Some things marked BROKEN may not be 100% broken and may actually
>> work for some specific things, so if you know that it works for your
>> use, then being able to easily enable BROKEN and then whatever it is
>> you need is nice.
>
> In reality, people accidentially turn on CONFIG_BROKEN, enable a broken
> driver, and wonder why it isn't working as expected.
so have CONFIG_BROKEN taint the kernel if you want to identify it in
bugreports.
> If you know the driver is marked as BROKEN and if you want to use it
> despite this, editing the Kconfig file is trivial.
>
> Unless you _really_ know what you are doing, no driver for your hard
> disk is better than a broken driver.
for your hard drive you are probably right, but does this always apply for
your network card? or your sound card?
>> Perhaps just move it below the Kernel Hacking menu instead, users
>> don't go there (or if they do they damn well should know what they are
>> doing).
>> ...
>
> Enabling MAGIC_SYSRQ for being able to sync the disks for crashed
> machines...
this is a reasonable option, although currently nothing in Kernel Hacking
enables items in other menus. it's convienient that when useing menuconfig
and working down from the top you first hit the selections that enable
things in all the other menus (experimental and broken).
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 18:26 ` Jesper Juhl
2006-01-06 18:39 ` Randy.Dunlap
@ 2006-01-06 19:14 ` Jan Engelhardt
1 sibling, 0 replies; 70+ messages in thread
From: Jan Engelhardt @ 2006-01-06 19:14 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Adrian Bunk, Andrew Morton, linux-kernel
>> And when do you really need it?
>>
>Hmm, when I'm looking for broken stuff to fix ;)
>I guess you are right, ordinary users don't need it.. Ok, count me in
>as supporting this move.
>
I go with it.
I had CONFIG_BROKEN on, which 'cost' me one post to LKML to find out that
CONFIG_MTD_AMD... does rightfully not compile. It (CONFIG_BROKEN/CLEAN_COMPILE)
just confuses.
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 18:39 ` Randy.Dunlap
@ 2006-01-06 18:58 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2006-01-06 18:58 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Jesper Juhl, Andrew Morton, linux-kernel
On Fri, Jan 06, 2006 at 10:39:30AM -0800, Randy.Dunlap wrote:
> On Fri, 6 Jan 2006, Jesper Juhl wrote:
>
> > On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> > > > On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > > > Do not allow people to create configurations with CONFIG_BROKEN=y.
> > > > >
> > > > > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > > > > fixing a broken driver, but in this case editing the Kconfig file is
> > > > > trivial.
> > > > >
> > > > > Never ever should a user enable CONFIG_BROKEN.
> > > > >
> > > > I disagree (slightly) with this patch for a few reasons:
> > > >
> > > > - It's very convenient to be able to enable it through menuconfig.
> > >
> > > And when do you really need it?
> > >
> > Hmm, when I'm looking for broken stuff to fix ;)
> > I guess you are right, ordinary users don't need it.. Ok, count me in
> > as supporting this move.
>
> I'm having a little trouble determining why it matters.
>
> Are you trying to cut down on lkml bug reports or just make
> it harder on everyone?
I'm trying to remove a small trap for users.
> ~Randy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 18:26 ` Jesper Juhl
@ 2006-01-06 18:39 ` Randy.Dunlap
2006-01-06 18:58 ` Adrian Bunk
2006-01-06 19:14 ` Jan Engelhardt
1 sibling, 1 reply; 70+ messages in thread
From: Randy.Dunlap @ 2006-01-06 18:39 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Adrian Bunk, Andrew Morton, linux-kernel
On Fri, 6 Jan 2006, Jesper Juhl wrote:
> On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> > > On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > > Do not allow people to create configurations with CONFIG_BROKEN=y.
> > > >
> > > > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > > > fixing a broken driver, but in this case editing the Kconfig file is
> > > > trivial.
> > > >
> > > > Never ever should a user enable CONFIG_BROKEN.
> > > >
> > > I disagree (slightly) with this patch for a few reasons:
> > >
> > > - It's very convenient to be able to enable it through menuconfig.
> >
> > And when do you really need it?
> >
> Hmm, when I'm looking for broken stuff to fix ;)
> I guess you are right, ordinary users don't need it.. Ok, count me in
> as supporting this move.
I'm having a little trouble determining why it matters.
Are you trying to cut down on lkml bug reports or just make
it harder on everyone?
--
~Randy
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 18:06 ` Adrian Bunk
@ 2006-01-06 18:26 ` Jesper Juhl
2006-01-06 18:39 ` Randy.Dunlap
2006-01-06 19:14 ` Jan Engelhardt
2006-01-06 21:11 ` David Lang
1 sibling, 2 replies; 70+ messages in thread
From: Jesper Juhl @ 2006-01-06 18:26 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel
On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> > On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > > Do not allow people to create configurations with CONFIG_BROKEN=y.
> > >
> > > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > > fixing a broken driver, but in this case editing the Kconfig file is
> > > trivial.
> > >
> > > Never ever should a user enable CONFIG_BROKEN.
> > >
> > I disagree (slightly) with this patch for a few reasons:
> >
> > - It's very convenient to be able to enable it through menuconfig.
>
> And when do you really need it?
>
Hmm, when I'm looking for broken stuff to fix ;)
I guess you are right, ordinary users don't need it.. Ok, count me in
as supporting this move.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 17:49 ` Jesper Juhl
@ 2006-01-06 18:06 ` Adrian Bunk
2006-01-06 18:26 ` Jesper Juhl
2006-01-06 21:11 ` David Lang
2006-01-06 22:25 ` Daniel Barkalow
1 sibling, 2 replies; 70+ messages in thread
From: Adrian Bunk @ 2006-01-06 18:06 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Andrew Morton, linux-kernel
On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
> >
> I disagree (slightly) with this patch for a few reasons:
>
> - It's very convenient to be able to enable it through menuconfig.
And when do you really need it?
> - Being able to easily enable it in menuconfig, then browse through
> the menus to look for something matching your hardware is nice, even
> if that something is marked BROKEN at least you've then found a place
> to start working on. A lot simpler than digging through directories.
Our menus are mostly made for _users_.
The more common are users accidentially enabling CONFIG_BROKEN and then
wondering why a driver isn't compiling or working.
And in my experience, when searching whether hardware might be supported
a grep through the kernel sources brings you more than reading often
outdated Kconfig help texts. Besides this, a BROKEN driver usually has
the same value for the user as a non-existing driver.
> - Some things marked BROKEN may not be 100% broken and may actually
> work for some specific things, so if you know that it works for your
> use, then being able to easily enable BROKEN and then whatever it is
> you need is nice.
In reality, people accidentially turn on CONFIG_BROKEN, enable a broken
driver, and wonder why it isn't working as expected.
If you know the driver is marked as BROKEN and if you want to use it
despite this, editing the Kconfig file is trivial.
Unless you _really_ know what you are doing, no driver for your hard
disk is better than a broken driver.
> Perhaps just move it below the Kernel Hacking menu instead, users
> don't go there (or if they do they damn well should know what they are
> doing).
>...
Enabling MAGIC_SYSRQ for being able to sync the disks for crashed
machines...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 17:41 ` Russell King
@ 2006-01-06 17:54 ` Adrian Bunk
0 siblings, 0 replies; 70+ messages in thread
From: Adrian Bunk @ 2006-01-06 17:54 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
On Fri, Jan 06, 2006 at 05:41:28PM +0000, Russell King wrote:
> On Fri, Jan 06, 2006 at 06:35:47PM +0100, Adrian Bunk wrote:
> > Do not allow people to create configurations with CONFIG_BROKEN=y.
> >
> > The sole reason for CONFIG_BROKEN=y would be if you are working on
> > fixing a broken driver, but in this case editing the Kconfig file is
> > trivial.
> >
> > Never ever should a user enable CONFIG_BROKEN.
>
> NACK. MTD_OBSOLETE_CHIPS still hasn't been fixed and must be fixed
> _before_ this patch can go in.
The MTD_OBSOLETE_CHIPS patch is also part of the batch of patches I'm
currently resending (it's coming in a few minutes).
@Andrew:
I agree with Russell on the ordering of the two patches.
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 17:35 [2.6 patch] don't allow users to " Adrian Bunk
2006-01-06 17:41 ` Russell King
@ 2006-01-06 17:49 ` Jesper Juhl
2006-01-06 18:06 ` Adrian Bunk
2006-01-06 22:25 ` Daniel Barkalow
1 sibling, 2 replies; 70+ messages in thread
From: Jesper Juhl @ 2006-01-06 17:49 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel
On 1/6/06, Adrian Bunk <bunk@stusta.de> wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
>
I disagree (slightly) with this patch for a few reasons:
- It's very convenient to be able to enable it through menuconfig.
- Being able to easily enable it in menuconfig, then browse through
the menus to look for something matching your hardware is nice, even
if that something is marked BROKEN at least you've then found a place
to start working on. A lot simpler than digging through directories.
- Some things marked BROKEN may not be 100% broken and may actually
work for some specific things, so if you know that it works for your
use, then being able to easily enable BROKEN and then whatever it is
you need is nice.
Perhaps just move it below the Kernel Hacking menu instead, users
don't go there (or if they do they damn well should know what they are
doing).
Ohh well, if it gets removed I won't really cry, but I do think it's
convenient, and if moved into Kernel Hacking it should be mostly out
of harms (read: users) way.
Just my 0.02euro
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
2006-01-06 17:35 [2.6 patch] don't allow users to " Adrian Bunk
@ 2006-01-06 17:41 ` Russell King
2006-01-06 17:54 ` Adrian Bunk
2006-01-06 17:49 ` Jesper Juhl
1 sibling, 1 reply; 70+ messages in thread
From: Russell King @ 2006-01-06 17:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel
On Fri, Jan 06, 2006 at 06:35:47PM +0100, Adrian Bunk wrote:
> Do not allow people to create configurations with CONFIG_BROKEN=y.
>
> The sole reason for CONFIG_BROKEN=y would be if you are working on
> fixing a broken driver, but in this case editing the Kconfig file is
> trivial.
>
> Never ever should a user enable CONFIG_BROKEN.
NACK. MTD_OBSOLETE_CHIPS still hasn't been fixed and must be fixed
_before_ this patch can go in.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 70+ messages in thread
* [2.6 patch] don't allow users to set CONFIG_BROKEN=y
@ 2006-01-06 17:35 Adrian Bunk
2006-01-06 17:41 ` Russell King
2006-01-06 17:49 ` Jesper Juhl
0 siblings, 2 replies; 70+ messages in thread
From: Adrian Bunk @ 2006-01-06 17:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Do not allow people to create configurations with CONFIG_BROKEN=y.
The sole reason for CONFIG_BROKEN=y would be if you are working on
fixing a broken driver, but in this case editing the Kconfig file is
trivial.
Never ever should a user enable CONFIG_BROKEN.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 13 Dec 2005
--- linux-2.6.15-rc5-mm2-full/init/Kconfig.old 2005-12-13 18:48:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/init/Kconfig 2005-12-13 18:48:52.000000000 +0100
@@ -31,19 +31,8 @@
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
-config CLEAN_COMPILE
- bool "Select only drivers expected to compile cleanly" if EXPERIMENTAL
- default y
- help
- Select this option if you don't even want to see the option
- to configure known-broken drivers.
-
- If unsure, say Y
-
config BROKEN
bool
- depends on !CLEAN_COMPILE
- default y
config BROKEN_ON_SMP
bool
^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~2006-01-19 1:40 UTC | newest]
Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-11 18:52 [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y Adrian Bunk
2005-12-11 18:52 ` Adrian Bunk
2005-12-11 18:52 ` Adrian Bunk
2005-12-11 19:21 ` Russell King
2005-12-11 19:21 ` Russell King
2005-12-11 19:31 ` Adrian Bunk
2005-12-11 19:31 ` Adrian Bunk
2005-12-11 19:44 ` Russell King
2005-12-11 19:44 ` Russell King
2005-12-13 0:10 ` Adrian Bunk
2005-12-13 0:10 ` Adrian Bunk
2005-12-13 0:10 ` Adrian Bunk
2005-12-13 13:34 ` Simon Richter
2005-12-13 13:34 ` Simon Richter
2005-12-13 13:34 ` Simon Richter
2005-12-13 14:00 ` Adrian Bunk
2005-12-13 14:00 ` Adrian Bunk
2005-12-13 14:00 ` Adrian Bunk
2005-12-13 14:00 ` Adrian Bunk
2005-12-13 17:31 ` Russell King
2005-12-13 17:31 ` Russell King
2005-12-13 17:31 ` Russell King
2005-12-13 17:38 ` Geert Uytterhoeven
2005-12-13 19:53 ` Russell King
2005-12-13 20:09 ` Adrian Bunk
2005-12-13 18:05 ` [2.6 patch] don't allow users to " Adrian Bunk
2005-12-13 18:05 ` Adrian Bunk
2005-12-13 18:05 ` Adrian Bunk
2005-12-13 18:28 ` Geert Uytterhoeven
2005-12-13 18:28 ` Geert Uytterhoeven
2005-12-13 18:28 ` Geert Uytterhoeven
2005-12-13 18:28 ` Geert Uytterhoeven
2005-12-13 18:51 ` Adrian Bunk
2005-12-13 18:51 ` Adrian Bunk
2005-12-13 18:51 ` Adrian Bunk
2005-12-13 18:51 ` Adrian Bunk
2005-12-13 18:59 ` Jesper Juhl
2005-12-13 18:59 ` Jesper Juhl
2005-12-13 18:59 ` Jesper Juhl
2005-12-13 18:59 ` Jesper Juhl
2005-12-13 20:01 ` Russell King
2005-12-13 20:01 ` Russell King
2005-12-13 20:01 ` Russell King
2005-12-13 20:19 ` Adrian Bunk
2005-12-13 20:19 ` Adrian Bunk
2005-12-13 20:19 ` Adrian Bunk
2005-12-13 22:01 ` Russell King
2005-12-13 22:01 ` Russell King
2005-12-13 22:01 ` Russell King
2005-12-12 9:38 ` [2.6 patch] defconfig's shouldn't " David Woodhouse
2005-12-12 9:38 ` David Woodhouse
2005-12-12 9:38 ` David Woodhouse
2005-12-13 0:05 ` [RFC: 2.6 patch] no longer mark MTD_OBSOLETE_CHIPS as BROKEN and remove broken MTD_OBSOLETE_CHIPS drivers Adrian Bunk
2005-12-13 0:06 ` Adrian Bunk
2005-12-14 11:50 ` [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y Richard Purdie
2006-01-06 17:35 [2.6 patch] don't allow users to " Adrian Bunk
2006-01-06 17:41 ` Russell King
2006-01-06 17:54 ` Adrian Bunk
2006-01-06 17:49 ` Jesper Juhl
2006-01-06 18:06 ` Adrian Bunk
2006-01-06 18:26 ` Jesper Juhl
2006-01-06 18:39 ` Randy.Dunlap
2006-01-06 18:58 ` Adrian Bunk
2006-01-06 19:14 ` Jan Engelhardt
2006-01-06 21:11 ` David Lang
2006-01-06 22:37 ` Adrian Bunk
2006-01-06 22:39 ` David Lang
2006-01-06 22:53 ` Adrian Bunk
2006-01-06 22:25 ` Daniel Barkalow
2006-01-19 1:40 Adrian Bunk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.