linux-kernel - Re: [PATCH v2 1/4] break kconfig dependency loop

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: <1428313821.634.116.camel@x220>
Date:	Mon, 06 Apr 2015 11:50:21 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Jani Nikula <jani.nikula@...ux.intel.com>
Cc:	Gerd Hoffmann <kraxel@...hat.com>, dri-devel@...ts.freedesktop.org,
	virtio-dev@...ts.oasis-open.org,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	mst@...hat.com, open list <linux-kernel@...r.kernel.org>,
	airlied@...hat.com,
	"open list:MEDIA INPUT INFRA..." <linux-media@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] break kconfig dependency loop

On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote:
> I think part of the problem is that "select" is often used not as
> documented [1] but rather as "show my config in menuconfig for
> convenience even if my dependency is not met, and select the dependency
> even though I know it can screw up the dependency chain".

Perhaps people use select because it offers, given the problem they
face, a reasonable way to make the kconfig tools generate a
sensible .config. It helps them to spend less time fiddling with Kconfig
files. And they expect that it helps others to configure their build
more easily, as it might save those others some work.

> In the big picture, it feels like menuconfig needs a way to display
> items whose dependencies are not met, and a way to recursively enable
> said items and all their dependencies when told.

How could that work its way through (multiple levels of) things like:
    depends on FOO || (BAZ && BAR)

> This would reduce the
> resistance to sticking with "select" when clearly "depends" is what's
> meant.

I had drafted a rather verbose response to this. But I think I'm not
really sure what you're saying here, probably because "select" and
"depends on" are rather different. How would you know that the actual
intention was to use "depends on"?


Paul Bolle

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