linux-kernel - Re: [ANNOUNCE] GSoC project: Improving kconfig using a SAT solver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 May 2010 14:07:06 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Vegard Nossum <vegard.nossum@...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 Wed, May 19, 2010 at 9:31 PM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> On 19 May 2010 13:05, Felipe Contreras <felipe.contreras@...il.com> wrote:
>> 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.

I see. As long as people can use .satconfig only if they want, I think
that's great.

>> 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).

Exactly. Well, I don't know if anybody considers that a problem, but
just check arch/arm/configs/*. All of them are much bigger than
needed, and some have not been updated in a long time (even as old as
2.6.11). So if you do make ARCH=arm assabet_defconfig and do a 'diff
.config assabet_defconfig' they would be completely different. This
way it's hard to keep track of the general config changes, and ARM
related changes, and OMAP3 changes, and compare with board-specific
ones.

Cheers.

-- 
Felipe Contreras
--
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/