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 14:50: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 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

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