From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756573Ab0ERGEB (ORCPT ); Tue, 18 May 2010 02:04:01 -0400 Received: from mail.lang.hm ([64.81.33.126]:35149 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755309Ab0ERGEA (ORCPT ); Tue, 18 May 2010 02:04:00 -0400 Date: Mon, 17 May 2010 23:03:10 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: James Bottomley cc: Vegard Nossum , Andi Kleen , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, Bart Massey , Michal Marek , Greg Kroah-Hartman , Ingo Molnar Subject: Re: [ANNOUNCE] GSoC project: Improving kconfig using a SAT solver In-Reply-To: <1274106526.4418.40.camel@mulgrave.site> Message-ID: References: <87tyq63eux.fsf@basil.nowhere.org> <1274102511.4418.18.camel@mulgrave.site> <1274106526.4418.40.camel@mulgrave.site> User-Agent: Alpine 2.01 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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