linux-kernel - Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

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]

Message-ID: <20150519000921.GA23057@wotan.suse.de>
Date:	Tue, 19 May 2015 02:09:21 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	rusty@...tcorp.com.au, dhowells@...hat.com, ming.lei@...onical.com,
	seth.forshee@...onical.com, kyle@...nel.org,
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
	keescook@...omium.org, casey@...aufler-ca.com, tiwai@...e.de,
	mjg59@...f.ucam.org, wireless-regdb@...ts.infradead.org,
	linux-wireless@...r.kernel.org, jlee@...e.com,
	linux-kernel@...r.kernel.org,
	Bruce Allan <bruce.w.allan@...el.com>,
	Tadeusz Struk <tadeusz.struk@...el.com>,
	John Griffin <john.griffin@...el.com>
Subject: Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when
 fw signing is enabled

On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> [...] so, probably, almost
> all .config files have FW_LOADER set. So I think, except for some corner
> cases, either converting all "select FW_LOADER" to "depends on
> FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> be fine.

Well, that makes sense. I just dropped all "select FW_LOADER" entries
on next-20150518, then I enabled everything with 'make allyesconfig'
and then went into menuconfig to disable FW_LOADER. The build worked.

Going to try a few more build matrix combinations and send patches to
do away with this.

> Those corner cases should then be handled on a case by case basis. 
> 
> > If not does this need to be fixed on kconfig?
> 
> There's no reason to think the logic of the kconfig tools, as it is
> currently implemented, is flawed. Feel free to convince me of the
> opposite.

Very well, thanks so much for your review and help.

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