linux-kernel - Re: [PATCH 17/17] BLOCK: Make it possible to disable the block layer [try #2]

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <E1GIQ2c-0000h3-T8@be1.lrz>
Date:	Wed, 30 Aug 2006 15:23:17 +0200
From:	Bodo Eggert <7eggert@...tempel.de>
To:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>,
	David Howells <dhowells@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/17] BLOCK: Make it possible to disable the block layer  [try #2]

Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> "select" would not be needed if the configurator wouldn't make an option
> _invisible_ if it depends on another disabled option. It would be nice
> if the option would stay visible (or better yet, would be optionally
> visible) and had pointers to unfulfilled dependencies.
> 
> Or more generally spoken, "select" would not be needed if there were
> other means to switch the configurator's UI to a layout that exposes
> more details about dependencies. There is already such a UI mode which
> fully exposes _fulfilled_ dependencies.

The "options with pointers to (unfullfilled) dependencies" that should be
visible are (or should be) exactly the options now using select. In other
words, only make fooconfig needs to be enheanced.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html
-
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/