linux-kernel - Re: [RFC v1] tree-wide: remove "select FW

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: <20150526004731.GB3965@x>
Date:	Mon, 25 May 2015 17:47:31 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	James Bottomley <jbottomley@...n.com>
Cc:	"rpurdie@...ys.net" <rpurdie@...ys.net>,
	"marcel@...tmann.org" <marcel@...tmann.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"clemens@...isch.de" <clemens@...isch.de>,
	"khalasa@...p.pl" <khalasa@...p.pl>,
	"3chas3@...il.com" <3chas3@...il.com>,
	"jesper.nilsson@...s.com" <jesper.nilsson@...s.com>,
	"johan.hedberg@...il.com" <johan.hedberg@...il.com>,
	"arnd@...db.de" <arnd@...db.de>,
	"kaloz@...nwrt.org" <kaloz@...nwrt.org>,
	"starvik@...s.com" <starvik@...s.com>,
	"tiwai@...e.de" <tiwai@...e.de>,
	"j.anaszewski@...sung.com" <j.anaszewski@...sung.com>,
	"pebolle@...cali.nl" <pebolle@...cali.nl>,
	"mcgrof@...not-panic.com" <mcgrof@...not-panic.com>,
	"ohad@...ery.com" <ohad@...ery.com>,
	"gustavo@...ovan.org" <gustavo@...ovan.org>,
	"cooloney@...il.com" <cooloney@...il.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"mcgrof@...e.com" <mcgrof@...e.com>,
	"jslaby@...e.cz" <jslaby@...e.cz>,
	"mchehab@....samsung.com" <mchehab@....samsung.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>,
	"bp@...en8.de" <bp@...en8.de>,
	"geert@...ux-m68k.org" <geert@...ux-m68k.org>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"airlied@...ux.ie" <airlied@...ux.ie>
Subject: Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

On Mon, May 25, 2015 at 09:29:51PM +0000, James Bottomley wrote:
> On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote:
> > On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote:
> > > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote:
> > > > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote:
> > > > > On Fri, 2015-05-22 at 14:43 -0700, josh@...htriplett.org wrote:
> > > > > > Ideally, someone should teach Kconfig to handle recursive dependencies,
> > > > > 
> > > > > I'm probably reading too much in this remark, but how should it handle
> > > > > that other than returning an error because the configuration it's fed
> > > > > makes it run in circles?
> > > > 
> > > > I don't mean cyclic dependencies (for which Kconfig should just report
> > > > an error, ideally including the full list of symbols forming the cycle).
> > > > 
> > > > I mean that Kconfig should do recursive dependency resolution.  If B
> > > > depends on A, and C depends on B, I should be able to turn on C
> > > > directly and have B and A enabled.
> > > 
> > > That's really hard in practise you have to make any symbol that selects
> > > something depend on the dependencies of the selected symbol.  You can't
> > > do this without involving a SAT solver.  A guy promised to do this a
> > > couple of years ago, but the patches never materialised.  However, they
> > > may exist somewhere if someone wants to take a look at completing it.
> > 
> > You can't do this in the completely general case without a SAT solver.
> > However, I think it's possible to help the user a bit more than than
> > Kconfig currently does without introducing a general dependency solver.
> 
> Well the logically simplest way of doing that it to require that a
> selected symbol can have no dependencies (but may select others) and to
> make this what Kconfig enforces ... of course, our current Kconfig tree
> violates this all over the place.

Or enforce that it has no disabled dependencies.

> > In particular, it'd be nice to have an easy way to see at a glance
> > "can't enable C because it depends on B", together with an easy way to
> > get to B to enable it to get to C.  User-guided dependency resolution
> > seems like an improvement over no dependency resolution.
> 
> Sure, but it's mostly people like us doing it and find . -name Kconfig\*
> -exec grep -3 <symbol> {} /dev/null \; usually does the trick for me.

That's not particularly convenient from the middle of menuconfig when
configuring a kernel.  It'd be nice to be able to navigate in one step
from a symbol to its dependencies within the menuconfig interface.

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