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 <[email protected]>
---
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
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
On 1/6/06, Adrian Bunk <[email protected]> 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 <[email protected]>
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
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
On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> On 1/6/06, Adrian Bunk <[email protected]> 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
On 1/6/06, Adrian Bunk <[email protected]> wrote:
> On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> > On 1/6/06, Adrian Bunk <[email protected]> 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 <[email protected]>
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
On Fri, 6 Jan 2006, Jesper Juhl wrote:
> On 1/6/06, Adrian Bunk <[email protected]> wrote:
> > On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> > > On 1/6/06, Adrian Bunk <[email protected]> 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
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 <[email protected]> wrote:
> > > On Fri, Jan 06, 2006 at 06:49:55PM +0100, Jesper Juhl wrote:
> > > > On 1/6/06, Adrian Bunk <[email protected]> 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
>> 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
--
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 <[email protected]> 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
On Fri, 6 Jan 2006, Jesper Juhl wrote:
> On 1/6/06, Adrian Bunk <[email protected]> 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*
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
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
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