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:	Fri, 01 Sep 2006 19:51:39 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Adrian Bunk <bunk@...sta.de>
CC:	Jörn Engel <joern@...nheim.fh-wedel.de>,
	David Woodhouse <dwmw2@...radead.org>,
	"Randy.Dunlap" <rdunlap@...otime.net>,
	Roman Zippel <zippel@...ux-m68k.org>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	David Howells <dhowells@...hat.com>,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 17/17] BLOCK: Make it possible to disable the block layer
 [try #2]

Adrian Bunk wrote:
> On Fri, Sep 01, 2006 at 06:19:20PM +0200, Jörn Engel wrote:
[...]
>> Assuming that select gets removed in the process, and
>> concentrating on oldconfig, would it be enough to have something like
>> this in the .config?
>> 
>> # CONFIG_USB_STORAGE has unmet dependencies: CONFIG_SCSI, CONFIG_BLOCK
>> 
>> Now people looking for usb mass storage can find the option without
>> grepping through Kconfig files, but also every single driver for every
>> single disabled subsystem shows up.  Might be a bit too much.

This comment or similar things are apparently not necessary _within 
subsystems_, just across subsystems, i.e. where the hierarchy of 
subdirectories and files does not match the hierarchy of dependencies.

> Common use case:
> A driver was changed to use FW_LOADER.
> The .config for the old kernel contains CONFIG_FW_LOADER=n.
> The user runs "make oldconfig" with the old .config in the new kernel.
> 
> How do you plan to handle this reasonably without select?

"make oldconfig" could ask questions when it sees need to disable 
formerly enabled options.

In general I think:
As long as we talk about the various prefab UIs to manipulate .config 
(i.e. "make {allyes, allmod, allno, def, g, menu, old, rand, silentold, 
update-po-, x, ''}config"), there may be ways to implement modes of 
operation which do what people expect from 'select' but with 'depends 
on' alone. To ensure that no user group is discriminated in the process, 
committees could be formed. (<- attempt on irony)

It will get difficult to entirely please users who don't use these 
interfaces to .config. But it seems these users are better off without 
'select'.
-- 
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/