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: <20070915144341.GT3563@stusta.de>
Date:	Sat, 15 Sep 2007 16:43:41 +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 04:11:45PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sat, Sep 15, 2007 at 03:20:06PM +0200, Stefan Richter wrote:
> >> It still doesn't entirely clarify whether users need sd, sr, st, and
> >> whether thy need sd for the disk with root filesystem.
> > 
> > If you want to do it in a really perfect way, help texts aren't the 
> > solution. You'll have to make the options like CONFIG_BLK_DEV_SR no 
> > longer be user visible and select'ed through dummy options like e.g.:
> ...
> > 	tristate "USB Mass Storage hard disk support"
> > 	depends on USB_STORAGE
> > 	select BLK_DEV_SD
> ...
> >         tristate "USB Mass Storage CD/DVD support"
> >         depends on USB_STORAGE
> > 	select BLK_DEV_SR
> ...
> 
> Perfect is in the eye of the beholder.  You would consequently have to
> add such options into all menus which contain scsi low-level providers.

Kconfig is a user interface, so perfect is what is best for the
kconfig users.

> Also, one more question on whether CONFIG_SCSI ought to be 'select'ed:
> Where do scsi-core options like CONFIG_SCSI_CONSTANTS go?

The first question is whether it's for actual SCSI hardware [1] or for 
the block layer functionality which the SCSI subsystem has become.
The mixture of these two is the root of much user confusion.

With the help text "The error messages regarding your SCSI hardware will 
be easier to understand if you say Y here" a user wouldn't have expected 
to see you using it in a firewire driver. But unless I miss anything, 
the setting of SCSI_SCAN_ASYNC does only affect "real" SCSI hardware.

If you check each option and place it either in the generic storage menu 
or the SCSI lowlevel menu this would fix much possible user confusion.

But these are relatively unimportant options compared to e.g.
USB_STORAGE=y, BLK_DEV_SD=n, which is a misconfiguration many
users run into, so having one menu somewhere with these advanced 
options should be enough.

> Stefan Richter

cu
Adrian

[1] SCSI as in "sold as SCSI"

-- 

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