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
| ||
|
Date: Tue, 26 May 2015 01:33:32 +0000 From: James Bottomley <jbottomley@...n.com> To: "josh@...htriplett.org" <josh@...htriplett.org> CC: "rpurdie@...ys.net" <rpurdie@...ys.net>, "marcel@...tmann.org" <marcel@...tmann.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "bp@...en8.de" <bp@...en8.de>, "clemens@...isch.de" <clemens@...isch.de>, "khalasa@...p.pl" <khalasa@...p.pl>, "jesper.nilsson@...s.com" <jesper.nilsson@...s.com>, "3chas3@...il.com" <3chas3@...il.com>, "johan.hedberg@...il.com" <johan.hedberg@...il.com>, "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>, "arnd@...db.de" <arnd@...db.de>, "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>, "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, 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@...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. 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
Powered by blists - more mailing lists