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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux