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]

Date:	Sat, 15 Sep 2007 13:40:55 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
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

On Fri, Sep 14, 2007 at 10:01:18PM +0200, Stefan Richter wrote:
> On 14 Sep, Adrian Bunk wrote:
> > On Fri, Sep 14, 2007 at 09:00:33PM +0200, Sam Ravnborg wrote:
> >> Hi Stefan.
> >> 
> >> Such a patch really calls for some minimal unifacation among
> >> the architectures.
> >> 
> >> > 
> >> >  arch/alpha/Kconfig            |    2 
> >> >  arch/arm/Kconfig              |    2 
> >> >  arch/avr32/Kconfig            |    2 
> >> >  arch/blackfin/Kconfig         |    2 
> >> >  arch/cris/Kconfig             |    2 
> >> >  arch/frv/Kconfig              |    2 
> >> >  arch/i386/Kconfig             |    2 
> >> >  arch/ia64/Kconfig             |    2 
> >> >  arch/m32r/Kconfig             |    2 
> >> >  arch/m68k/Kconfig             |    2 
> >> >  arch/m68knommu/Kconfig        |    2 
> >> >  arch/mips/Kconfig             |    2 
> >> >  arch/parisc/Kconfig           |    2 
> >> >  arch/powerpc/Kconfig          |    2 
> >> >  arch/ppc/Kconfig              |    2 
> >> >  arch/s390/Kconfig             |    2 
> >> >  arch/sh/Kconfig               |    2 
> >> >  arch/sh64/Kconfig             |    2 
> >> >  arch/sparc/Kconfig            |    2 
> >> >  arch/sparc64/Kconfig          |    2 
> >> >  arch/um/Kconfig               |    2 
> >> >  arch/v850/Kconfig             |    2 
> >> >  arch/x86_64/Kconfig           |    4 
> >> >  arch/xtensa/Kconfig           |    2 
> >> 
> >> 
> >> Exactly the same change for all architectures.
> >> IT would be good to introduce a common file that contains
> >> some of the shared stuff from the different architectures.
> >> We could start out simple with:
> >> 
> >> arch/Kconfig.arch:
> >>...
> 
> Yes, that would be good.  But Adrian has a point too.
> 
> > Stefan simply shouldn't move it out of drivers/Kconfig.
>...
>  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.

> Index: linux-2.6.23-rc6/drivers/Kconfig
> ===================================================================
> --- linux-2.6.23-rc6.orig/drivers/Kconfig
> +++ linux-2.6.23-rc6/drivers/Kconfig
> @@ -1,5 +1,7 @@
>  # 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,...

> Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
> ===================================================================
> --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
> +++ linux-2.6.23-rc6/drivers/scsi/Kconfig
> @@ -1,14 +1,7 @@
> -menu "SCSI device support"
> -
> -config RAID_ATTRS
> -	tristate "RAID Transport Class"
> -	default n
> -	depends on BLOCK
> -	---help---
> -	  Provides RAID
> +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?

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.

> 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

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