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

[Adrian Bunk <bunk@kernel.org>]

On Sat, Sep 15, 2007 at 02:24:17PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
>...
> >>  # 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?

It's different since _all_ network device drivers require networking 
support.

> 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?  ...?

Different to CONFIG_SCSI, CONFIG_NET=n is so exotic that we should 
change it to no longer show users the question unless CONFIG_EMBEDDED=y.

> > 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.

If users who don't need it now enable CONFIG_SCSI (and drivers/ide/ 
usage is not that uncommon) that's a regression in the user interface.

If the lowlevel SCSI drivers move into a separate menu as your patch 
does, we simply no longer have any good reason for bothering the user 
with the CONFIG_SCSI.

> Stefan Richter

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed