Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y

[Daniel Barkalow]

On Fri, 6 Jan 2006, Jesper Juhl wrote:

> On 1/6/06, Adrian Bunk <bunk@xxxxxxxxx> 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*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/