On 19 May 2010 13:05, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > On Mon, May 17, 2010 at 3:02 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> 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-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
