[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTik4gyHBrCAfnVogj-DiEHkp3b1OlSYcja1pJ83R@mail.gmail.com>
Date: Wed, 19 May 2010 20:31:25 +0200
From: Vegard Nossum <vegard.nossum@...il.com>
To: Felipe Contreras <felipe.contreras@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
Bart Massey <bart@...pdx.edu>, Michal Marek <mmarek@...e.cz>,
Greg Kroah-Hartman <greg@...ah.com>,
Ingo Molnar <mingo@...e.hu>,
James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [ANNOUNCE] GSoC project: Improving kconfig using a SAT solver
On 19 May 2010 13:05, Felipe Contreras <felipe.contreras@...il.com> wrote:
> On Mon, May 17, 2010 at 3:02 PM, Vegard Nossum <vegard.nossum@...il.com> wrote:
>> Hi,
>>
>> I just wanted to say that I've been accepted into this year's Google
>> Summer of Code program and will spend this summer working on improving
>> the kconfig system in a very particular direction: I want to integrate
>> a proper boolean constraint satisfiability solver into the
>> configuration editors (menuconfig, etc.) in order to allow
>> partial/incomplete configuration specifications. In short, this means
>> that the user can choose to not specify a particular value for some
>> config options, but let the system deduce their values. This will
>> hopefully improve usability and also solve the select problem once and
>> for all.
>
> Very nice! I thought on this idea too.
>
> Does this means that if you have a pristine kernel, and you do 'make
> menuconfig' and don't change anything, the .config file will be empty?
> And then, anything that you change will be in the .config file?
>
Yes and no -- I think the plan is to retain the .config file as it is
(i.e. it specifies more or less every option completely), so that it
remains backwards compatible; bisection, for example, is very
important. But yes, I think there will be a new file, say, .satconfig,
which contains only the specific choices of the user. And this one
would be empty, as you say, with a pristine kernel.
I think, then, that the .config file will be regenerated from the
.satconfig one each time .satconfig changes.
> On another case I do 'make ARCH=arm omap3_beagle_defconfig' then my
> .config file will point to that particular defconfig, and I can add
> only the changes that I want. Also, omap3_beagle_defconfig probably
> points omap3_defconfig and only makes certain changes.
>
> If so, that would be awesome :)
Do you mean essentially a sort of cascade of configurations that
inherit options from a different file? That shouldn't be very hard to
do -- I'll make a note of it for when I get that far! That has the
potential to make the defconfig files a bit shorter and more
manageable (not sure how big a problem that is in practice today,
though).
Thanks,
Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists