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

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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/