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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 30 Aug 2006 13:29:31 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Roman Zippel <zippel@...ux-m68k.org>
CC:	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]

Roman Zippel wrote:
> On Tue, 29 Aug 2006, Stefan Richter wrote:
[...]
>> The kernel configuration is currently presented as a tree, although the
>> dependencies of config options are not a tree. That's were "select" helps.
> 
> Actually dependencies are a tree and kconfig verifies that it's valid as 
> well and that's there "select" can wreak havoc.

OK. You are right, they are both trees. But the menu tree is different
from the dependency tree. I can see two reasons: 1. We expect the menu's
layout to reflect function rather than implementation. 2. Menu tree and
dependency tree are directed trees, but only the menu tree has a root
(i.e. _one_ root).

> select really creates a reverse dependency, i.e. the value of SCSI depends 
> now on the USB_STORAGE value.

It doesn't really revert the dependency. It changes the path that the
user takes to enable interdependent options. Thereby it changes _how_
the configurator ensures (or rather, _should_ ensure) that dependencies
are fulfilled.

> This means now that all dependencies of the 
> selected symbol have to be selected as well (either by the selecting 
> symbol or by the selected symbol). With more complex dependencies this can
> quickly get out of hand in order to maintain a valid and correct 
> dependency tree. That's why I'm not really happy about the current massive 
> use of select and I'd rather find solutions with normal dependencies, 
> which unfortunately isn't trivial, select OTOH was a simple hack.

"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.
-- 
Stefan Richter
-=====-=-==- =--- ====-
http://arcgraph.de/sr/
-
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/