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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
