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: <46EBF9DC.1000503@s5r6.in-berlin.de>
Date:	Sat, 15 Sep 2007 17:27:24 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Adrian Bunk <bunk@...nel.org>
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

Adrian Bunk wrote:
> On Sat, Sep 15, 2007 at 04:11:45PM +0200, Stefan Richter wrote:
>> 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.

Duplicate options with different names in different menus, but which all
do the same, --- is this the best for 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.

FireWire hardware which implements SBP-2 is SCSI hardware...  But this
detail aside --- yes, of course this help text is old and misleading.

> But unless I miss anything, 
> the setting of SCSI_SCAN_ASYNC does only affect "real" SCSI hardware.

It affects every hardware which is driven by scsi low-level providers
which have been integrated with the SCSI_SCAN_ASYNC facility.

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

True.

So,
    config SCSI_CONSTANTS
        "Kernel log messages from the SCSI subsystem will be easier to
        understand if you say Y here..."
would say what this option really does.  But to some degree the need to
explain what the SCSI subsystem or SCSI core is and which other
subsystems make use of it remains.  Maybe it's OK to provide
documentation of this kind outside of Kconfig help though.

> [1] SCSI as in "sold as SCSI"

Difficult.  Does e.g. hardware sold as SAS count as "sold as SCSI"?  How
about SBP-2 then?  ;-)
-- 
Stefan Richter
-=====-=-=== =--= -====
http://arcgraph.de/sr/
-
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/