linux-kernel - Re: [RFC PATCH] SCSI: split Kconfig menu into two

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: <46EBCEF1.4030702@s5r6.in-berlin.de>
Date:	Sat, 15 Sep 2007 14:24:17 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Sam Ravnborg <sam@...nborg.org>,
	James Bottomley <james.bottomley@...eleye.com>,
	linux-scsi@...r.kernel.org, Jeff Garzik <jeff@...zik.org>,
	Andi Kleen <andi@...stfloor.org>,
	Folkert van Heusden <folkert@...heusden.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] SCSI: split Kconfig menu into two

Adrian Bunk wrote:
> On Fri, Sep 14, 2007 at 10:01:18PM +0200, Stefan Richter wrote:
>>  drivers/Kconfig               |    4 
>>  drivers/scsi/Kconfig          | 1589 ----------------------------------
>>  drivers/scsi/Kconfig.lowlevel | 1578 +++++++++++++++++++++++++++++++++
>>  3 files changed, 1588 insertions(+), 1583 deletions(-)
> 
> Nearly right.  ;-)
> 
> There are a few architectures not (yet) using drivers/Kconfig.

Right, the patch is wrong for those architectures which include
drivers/scsi/Kconfig directly, rather than indirectly via drivers/Kconfig.

[...]
>>  # drivers/Kconfig
>>  
>> +source "drivers/scsi/Kconfig"
>> +
>>  menu "Device Drivers"
>>  
>>  source "drivers/base/Kconfig"
>> @@ -22,7 +24,7 @@ source "drivers/misc/Kconfig"
>>  
>>  source "drivers/ide/Kconfig"
>>  
>> -source "drivers/scsi/Kconfig"
>> +source "drivers/scsi/Kconfig.lowlevel"
>>  
>>  source "drivers/ata/Kconfig"
>> ...
> 
> This way the order is wrong:
> 
> There should first be the lowlevel SCSI, SATA, USB etc. drivers, these 
> drivers should select CONFIG_SCSI, and then the menu offering support 
> for disk, CD,...

The order was inspired by

	# the protocols etc.
	"Networking"

	# the interconnects
	"Device Drivers"/ "Network device support"

So that order is wrong too?

However, there is also precedence for the order which you suggest:  The
partition and filesystems options come after device driver options.

[...]
>> +menu "Storage (core and SCSI commands)"
>>  
>>  config SCSI
>> -	tristate "SCSI device support"
>> +	tristate "Storage support (core and SCSI commands)"
>>  	depends on BLOCK
>>  	select SCSI_DMA if HAS_DMA
>>  	---help---
>> ...
> 
> What is "storage support"?
> SATA?
> PATA?
> USB mass storage?
> MMC?
> MTD?

What is "Networking"?  Ethernet?  Infiniband?  ...?

> Whether or not a driver uses the SCSI layer is an implementation detail 
> (it even differs for the two USB mass storage implementations and the 
> two PATA implementations in the kernel) the user shouldn't have to know 
> about.
> 
> I don't see any reason why CONFIG_SCSI should have to stay user-visible 
> at all after your patch.

Vice versa, I don't see any reason for "select SCSI" anywhere after my
patch.
-- 
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/