Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

[James Bottomley <jbottomley@odin.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3353 bytes --]

On Mon, 2015-05-25 at 17:47 -0700, Josh Triplett wrote:
> 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@joshtriplett.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.

That's what doesn't work: once you depend on a symbol that selects
something else, you have to evaluate the satisfiability condition again
recursively ... and that's a SAT solver.  Unfortunately, you need either
a heuristic that makes the logic chains simple or resign yourself to
doing it properly.

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

Well, it works for me but, sure, do something you prefer ... I use make
config rather than menuconfig anyway.

James

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥