All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: Adrian Bunk <bunk@stusta.de>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y
Date: Fri, 6 Jan 2006 17:25:57 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0601061705320.25300@iabervon.org> (raw)
In-Reply-To: <9a8748490601060949g4765a4dcrfab4adab4224b5ad@mail.gmail.com>

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*

  parent reply	other threads:[~2006-01-06 22:24 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-06 17:35 [2.6 patch] don't allow users to set CONFIG_BROKEN=y 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 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-01-19  1:40 Adrian Bunk
2005-12-11 18:52 [2.6 patch] defconfig's shouldn't " Adrian Bunk
2005-12-11 19:21 ` Russell King
2005-12-11 19:31   ` Adrian Bunk
2005-12-11 19:44     ` Russell King
2005-12-13  0:10       ` Adrian Bunk
2005-12-13 13:34         ` Simon Richter
2005-12-13 14:00           ` Adrian Bunk
2005-12-13 17:31             ` Russell King
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

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=Pine.LNX.4.64.0601061705320.25300@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=akpm@osdl.org \
    --cc=bunk@stusta.de \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.