mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: david@lang.hm
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
	Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
	Bart Massey <bart@cs.pdx.edu>, Michal Marek <mmarek@suse.cz>,
	Greg Kroah-Hartman <greg@kroah.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [ANNOUNCE] GSoC project: Improving kconfig using a SAT solver
Date: Mon, 17 May 2010 23:03:10 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.01.1005172258360.27232@asgard.lang.hm> (raw)
In-Reply-To: <1274106526.4418.40.camel@mulgrave.site>

On Mon, 17 May 2010, James Bottomley wrote:

> On Mon, 2010-05-17 at 16:21 +0200, Vegard Nossum wrote:
>> On 17 May 2010 15:21, James Bottomley
>>
>> Even if the problem is different from zypper's, it is also here
>> possible to get an unsatisfiable instance. You are right that, yes,
>> the kconfig files on their own should always be satisfiable. But
>> that's before the user has made any choices at all. An example of an
>> unsatisfiable instance would be one where the user demands that 1.
>> some USB driver is enabled, while 2. USB support in general is
>> disabled.
>
> Actually, these are two separate problems.  The first is basic
> consistency within the Kconfig subsytstem (something that select
> currently damages for us).  The second is what to present to the user,
> which is where the inception of the select problem came from.  A user
> doesn't really want to know that USB device X depends on usb storage,
> SCSI and a raft of other things ... they just want it to configure a
> kernel that supports their device.  In particular, we don't want to
> present every possible option to users and then try to work out a
> solution, we really need guided configuration (which, in some measure,
> is what we have today: if you don't select general USB, you won't see
> any USB drivers.  Or more importantly, if you select an Adaptec SCSI
> card, we just enable whichever transport library it needs).

There are two modes people can be in when configuring a kernel.

1. I want to configure a kernel to support my hardware, enable anything 
else needed to make it work.

2. I really care about having a small kernel, don't enable anything I have 
disabled (but help me figure out why something I want isn't available)

I don't think that hiding hardware from the user is ever the best thing to 
do. for approach #1 you obviously don't want to hide anything, but even 
for approach #2, someone may not realize that by disabling one option they 
are making it impossible to support something, and as someone who spent a 
bunch of time hunting through config to find options that I ended up 
finding were not available without enabling something else, I much prefer 
to see the option, but see it disabled rather than not being sure if it 
should be there, or somewhere else in the config.

David Lang

  reply	other threads:[~2010-05-18  6:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-17 12:02 Vegard Nossum
2010-05-17 12:13 ` Andi Kleen
2010-05-17 13:09   ` Vegard Nossum
2010-05-17 13:21     ` James Bottomley
2010-05-17 14:21       ` Vegard Nossum
2010-05-17 14:28         ` James Bottomley
2010-05-18  6:03           ` david [this message]
2010-05-18 12:26             ` Jon Smirl
2010-05-18 12:54               ` Vegard Nossum
2010-05-18 13:42                 ` kevin granade
2010-06-10 13:55             ` Pavel Machek
2010-05-17 14:18     ` Andi Kleen
2010-05-19 11:05 ` Felipe Contreras
2010-05-19 18:31   ` Vegard Nossum
2010-05-21 11:07     ` Felipe Contreras

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=alpine.DEB.2.01.1005172258360.27232@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=andi@firstfloor.org \
    --cc=bart@cs.pdx.edu \
    --cc=greg@kroah.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mmarek@suse.cz \
    --cc=vegard.nossum@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®