linux-kernel - Re: [PATCH 2/2] Enable 'make CONFIG

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:	Thu, 11 Aug 2011 16:07:23 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Arnaud Lacombe <lacombar@...il.com>
Cc:	Michal Marek <mmarek@...e.cz>, Andreas Schwab <schwab@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 2/2] Enable 'make CONFIG_FOO=y oldconfig'

On Thu, 2011-08-11 at 10:57 -0400, Arnaud Lacombe wrote:
> 
> FWIW, this is the broken behavior I have been pointing all along...
> 
> If kconfig hard failed on such case, we would not need such Kbuild
> black-magic.
> 
> From my point of view, if environment override there should be, it
> should behave the same as the all.config logic and hard fail when an
> override has not been met. 
> Code wise, this would translate as backend code path being the same. 

The patches I have so far *do* behave the same as the all.config logic,
because the back end code *is* fairly much the same. I was looking at
the all.config logic when I wrote the patch to kconfig.

It *doesn't* currently hard fail. But I'm more than happy to make it do
so. I think you're right; that makes most sense.

I've just been looking at ways to allow real build targets to proceed
*only* if any config options specified on the command line *did* get
honoured by kconfig. But that gets a bit messy since you also want to
automatically trigger an 'oldconfig' run if anything was specified on
the command line. So you end up with one automatic oldconfig run in a
sub-make, then the *second* time around it when the supposedly identical
submake is invoked for the real build target, it would have to behave
differently.

I'm much happier with automatically triggering a reconfig if options are
given on the command line, and a hard fail if they can't be honoured.

That means that 'make CONFIG_FOO=y bzImage' will work 'properly', which
IMO is either to do as it was asked, or fail.

-- 
dwmw2

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