lkml.org 
[lkml]   [2006]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-01 19:59    [W:0.143 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site