All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Simon Richter <Simon.Richter@hogyros.de>,
	linux-kernel@vger.kernel.org, tony.luck@intel.com,
	linux-ia64@vger.kernel.org, matthew@wil.cx,
	grundler@parisc-linux.org, parisc-linux@parisc-linux.org,
	paulus@samba.org, linuxppc-dev@ozlabs.org, lethal@linux-sh.org,
	kkojima@rr.iij4u.or.jp, dwmw2@infradead.org,
	linux-mtd@lists.infradead.org
Subject: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
Date: Tue, 13 Dec 2005 19:05:52 +0100	[thread overview]
Message-ID: <20051213180551.GN23349@stusta.de> (raw)
In-Reply-To: <20051213173112.GA24094@flint.arm.linux.org.uk>

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


WARNING: multiple messages have this Message-ID (diff)
From: Adrian Bunk <bunk@stusta.de>
To: Simon Richter <Simon.Richter@hogyros.de>,
	linux-kernel@vger.kernel.org, tony.luck@intel.com,
	linux-ia64@vger.kernel.org, matthew@wil.cx,
	grundler@parisc-linux.org, parisc-linux@parisc-linux.org,
	paulus@samba.org, linuxppc-dev@ozlabs.org, lethal@linux-sh.org,
	kkojima@rr.iij4u.or.jp, dwmw2@infradead.org,
	linux-mtd@lists.infradead.org
Subject: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
Date: Tue, 13 Dec 2005 18:05:59 -0000	[thread overview]
Message-ID: <20051213180551.GN23349@stusta.de> (raw)
In-Reply-To: <20051213173112.GA24094@flint.arm.linux.org.uk>

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

WARNING: multiple messages have this Message-ID (diff)
From: Adrian Bunk <bunk@stusta.de>
To: Simon Richter <Simon.Richter@hogyros.de>,
	linux-kernel@vger.kernel.org, tony.luck@intel.com,
	linux-ia64@vger.kernel.org, matthew@wil.cx,
	grundler@parisc-linux.org, parisc-linux@parisc-linux.org,
	paulus@samba.org, linuxppc-dev@ozlabs.org, lethal@linux-sh.org,
	kkojima@rr.iij4u.or.jp, dwmw2@infradead.org,
	linux-mtd@lists.infradead.org
Subject: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
Date: Tue, 13 Dec 2005 18:05:52 +0000	[thread overview]
Message-ID: <20051213180551.GN23349@stusta.de> (raw)
In-Reply-To: <20051213173112.GA24094@flint.arm.linux.org.uk>

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


  parent reply	other threads:[~2005-12-13 18:05 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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               ` Adrian Bunk [this message]
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: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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051213180551.GN23349@stusta.de \
    --to=bunk@stusta.de \
    --cc=Simon.Richter@hogyros.de \
    --cc=dwmw2@infradead.org \
    --cc=grundler@parisc-linux.org \
    --cc=kkojima@rr.iij4u.or.jp \
    --cc=lethal@linux-sh.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=matthew@wil.cx \
    --cc=parisc-linux@parisc-linux.org \
    --cc=paulus@samba.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.